🚀 go-pugleaf

In de.comm.uucp, article <ohMBr*-+1@germal.bs.open.de>,
  gm@germal.bs.open.de (Gerald Malitz) writes:
> In article <17nahcINN818@smurf.smurf.sub.org>, Matthias Urlichs writes:
> 
> > Das stimmt nicht ganz. Das erste Paket wird eine fehlerhafte Pruefsumme
> > haben; der uucico sollte(!!) dann eigentlich in den Daten dieses Pakets nach
> > einem vernuenftigen Header suchen und den dann als Paketanfang erkennen.
> 
>         Hmm, das hoert sich natuerlich erstmal prima an.  Aber wie oft
> kann der uucico das so wiedergefundene Paket auch gebrauchen solange
> es kein selektives Reject gibt (oder kann Taylor das inzwischen auch?)?
> Es wird doch das mit der naechsten Sequenznummer sein, weil ich mein
> Reject ja noch gar nicht gesendet hatte, als ich die Bytes gelesen habe.
> 
- Vielleicht _ist_ das Paket, das da geschossen wird, die Antwort auf dein
  Reject.
- Wenn der uucico das Paket mit der falschen Nummer sieht, koennte er auf die
  Idee kommen, ein Reject zu senden. Wenn er dagegen nur Datenmuell liest,
  bleibt ihm nichts anderes uebrig, als auf einen Timeout zu warten.

> > > das `37777777' in `rec h->cntl 37777777611' mach mich skeptisch ;-)
> >
> > Das ist typisch Vorzeichenerweiterung eines chars und hat damit zu tun, dass
> > diverse Idioten vergessen haben, an den entsprechenden Stellen ein &0377
> > dazuzuschreiben.
> 
>         ...oder dem char ein unsigned zu verpassen, wo man doch mit dem
> char eigentlich byte meint...
> 
"unsigned char"? Du unterschaetzst das Alter der UUCP-Software -- damals
war "unsigned" ein Synonym fuer "unsigned int". Siehe K&R, erste Ausgabe.
Vergiss nicht, dass der UUCP-g-code so haesslich ist, dass es einfacher ist,
den Code neuzuschreiben, als ihn zu verstehen -- und selbst das hat sich
jahrelang keiner zugetraut.  ;-)

-- 
The Kennedy Constant:
        Don't get mad -- get even.
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/