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

  • From: Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx>
  • To: archimedes@xxxxxxxxxxxxx
  • Date: Sat, 24 May 2014 13:01:39 +0200

In message <2728bb0c54.cms@xxxxxxxxxxxxxxx>
          Carlos Michael Santillan <ml-archimedes@xxxxxxxxxx> wrote:

[Teil der vorherigen Antwort weggeschnitten]

Danke erstmal für deine tatkräftige Unterstützung und Mithilfe!

>> 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.

Es gibt jetzt ein neues Problem: !Pluto kann die E-Mail nicht
verarbeiten, wenn da lauter [0D] <CR> daherkommen (Wagenrücklauf). Daher
müssen diese Zeichen ebenfalls rausgefiltert werden. Nun ist es aber so,
dass damit die Größe der E-Mail verändert wird. Oh, Mann.

Schönes Wochenende wünscht euch allen

Alex

-- 
http://home.chiemgau-net.de/ausserstorfer/
Sent wirelessly from RISC OS per LTE


Other related posts: