[archimedes] Re: Wie <Obey$Dir>-Variable von C-Quellcode aus nutzen?

  • From: Carlos Michael Santillan <ml-archimedes@xxxxxxxxxx>
  • To: archimedes@xxxxxxxxxxxxx
  • Date: Sat, 24 May 2014 10:20:49 +0200

On 24 May 2014  Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> wrote:
>> ausprobieren und messen. Du kennst OS_GBPB? Damit kannst Du den
>Nein, kannte ich noch nicht. Ich sehe es mir 'mal an.

Hier ein kleines Beispiel in BASIC, aus meinen Experimentierverzeichnis.
Das Kopiert eine Datei. Das Programm ermittelt erst Mal ein paar Daten.
Da die Datei stückchenweise im Speicher abgelegt wird (buffer%), wird
auch berechnet wieviele Runden es braucht um die Datei zu kopieren. Dann
wird die Datei via Puffer kopiert. An der neuen Datei wird einfach
"_neu" angehängt. Im Programm muss noch der Dateiname (src_file$)
angegeben werden.

Das war und ist kein Programm für die Wildnis, sondern nur zum
Ausprobieren wie man das mit OS_GBPB macht. Das sollt aber schneller
sein, als wenn man das mit reinen C-Funktionen macht.


>Die Frage war, wenn !POPStar 7 Nullen für die Größenangabe der
>E-Mail in der Zeile "#! rmail 00..." verwendet (0000000), aber eine
>E-Mail größer ist (z. B. 10 MB bis 100 MB), dann ist kein Platz mehr, um
>in der Zeile "#! rmail 00..." die Größe noch komplett anzugeben. Was
>passiert dann?
>
>Mit Pufferüberlauf hat das meiner Auffassung nach nichts zu tun.

>Den Dateizeiger verschieben, genau darauf arbeite ich gerade hin. Zuerst
>werden 12 Nullen in der Zeile "#! rmail 000000000000" geschrieben, und,
>_nachdem_ die E-Mail geschrieben und gezählt worden ist, der Dateizeiger
>verschoben und _nachträglich_ die gezählte Größe eingetragen. Erst
>_danach_ geht es mit der nächsten E-Mail weiter.

Das habe ich missverstanden. Aber wie ich schrieb würde es reichen, erst
mal anzunehmen, das die LIST Angabe stimmt und nur wenn die nicht stimmt
muss man die korrigieren. Das spart sicher etwas Zeit bei der
Ausführung. Mails die größer als 9.999.999 Bytes sind, müssen schon
verarbeitbar sein. Auch wenn man dann bei einen Risc PC die Kanne Kaffee
Zeit dafür braucht.

Ja, das ist kein Pufferüberlauf. Aber ein falscher Wert hinter rmail
könnte den in Messenger/Pluto erzeugen.



Carlos Michael Santillán

--
http://www.arcsite.de/
http://www.risc-os.de/

Ein Staat, in dem alle verdächtig sind, ist selbst verdächtig
A state that suspects everyone is itself suspicious

Attachment: mfc3.zip
Description: Zip archive

Other related posts: