Closed bictorv closed 3 years ago
I tested a regular TCP supdup to up.update.uu.se, and it didn't work. The old supdup works.
$ ./supdup up.update.uu.se
Trying 130.238.19.215 port 95 ...Connected to up.update.uu.se.
Escape character is "C-^".
UPdate KLH-10
Connection closed by up.update.uu.se.
"it works for me", so could you be more specific about what doesn't work? Possibly run with -d when it doesn't work?
Here's the output when run with -d. If you like, you can get an account on my machine.
(Side note: Do we want SAIL characters or CR LF here?)
connect(server): No such file or directory
setsockopt (SO_DEBUG): Invalid argument
Trying 130.238.19.215 port 95 ...Connected to up.update.uu.se.
Escape character is "C-^".
State: 0, Incoming: 0125. Translation: U
State: 0, Incoming: 0120. Translation: P
State: 0, Incoming: 0144. Translation: d
State: 0, Incoming: 0141. Translation: a
State: 0, Incoming: 0164. Translation: t
State: 0, Incoming: 0145. Translation: e
State: 0, Incoming: 040. Translation:
State: 0, Incoming: 0113. Translation: K
State: 0, Incoming: 0114. Translation: L
State: 0, Incoming: 0110. Translation: H
State: 0, Incoming: 055. Translation: -
State: 0, Incoming: 061. Translation: 1
State: 0, Incoming: 060. Translation: 0
State: 0, Incoming: 015. Translation: circled plus
State: 0, Incoming: 012. Translation: delta
UPdate KLH-10
Connection closed by up.update.uu.se.
It's gcc which treats a plain "char" declaration as "unsigned char". Changing inits from "char" to "signed char" makes it work also on Linux. (Why does it do that? Is it some new stupid standard?)
Sorry, not quite sufficient: being in a hurry, just #if 0 ... #endif around adding the new Supdup variables at the end of sup_term() makes it, for now.
(The translation is not actually done until the first TDNOP, as per one of my recent patches.)
It's gcc which treats a plain "char" declaration as "unsigned char". Changing inits from "char" to "signed char" makes it work also on Linux. (Why does it do that? Is it some new stupid standard?)
The sign of 'char' is unspecified in C -- if you depend on the sign of char you must specify it. This has always been the case in C.
Oh, a language lawyer thread!
It's certainly true that the signedness of char in C is unspecified, but an argument can be made that changing this choice on a particular platform isn't a good practice. Programs that once worked may suddenly break, potentially making lots of people unhappy or worse, silently hiding security problems.
Oh, a language lawyer thread!
It's certainly true that the signedness of char in C is unspecified, but an argument can be made that changing this choice on a particular platform isn't a good practice. Programs that once worked may suddenly break, potentially making lots of people unhappy or worse, silently hiding security problems.
Welcome to the world of C. :-)
Next time I have too much time, I'll rewrite everything in a high-level language...
Portable CLU maybe?
I don't know if it's applicable here, but ITS also handles 40k, 50k, and 80k bits/s.
I know (now), but "unix" doesn't. And really, nobody seems to care. :-)
FWIW, this breaks on OpenBSD. Mostly due to the fact that -lresolv doesn't exist there (nor on some other BSDs), normally these days the libresolv stuff is provided directly by libc both on BSDs and GNU systems but OS X seems to not have followed suite? Dynamically adding -lresolv to the linker line is slightly tricky to do in some form of portable Make -- since everyone wants to be special.
autoconf, anyone? Also, feel free to add some #ifdef to avoid the DNS code and just look for numeric chaos addresses? But also, not all resolver libraries are equivalent, as I discovered implementing the DNS part of cbridge. I forgot the details, I'm afraid, but if you would try to get it working on OpenBSD you might discover?
I'd like to avoid autoconf/automake, mostly since this is such a tiny program. And it brings its own set of complications (generating the configure scripts, on OpenBSD one needs to export a few environment variables for it to work well, etc)... But I'll see what I can figure out both for supdup, and cbridge (where I think I have some autoconf hackery pending?).
f the host parameter given can be on Chaosnet (based on DNS or that it's a valid 16-bit chaos address, and that cbridge allows a connection), connect using the stream interface of cbridge, else use Internet as usual.
Also send three extra Supdup variables (supported by ITS), and some minor things.