[gforth] unix/socket.fs bug
Josh Grams
divide-by-zero error. Replacing `um/mod` with `ud/mod drop` fixes this.
--Josh
Anton Ertl
>On 32-bit Linux systems, ms@ usually overflows um/mod, throwing a
>divide-by-zero error. Replacing `um/mod` with `ud/mod drop` fixes this.
No, it doesn't. The overflow is still there, but with this "fix" it
just leads to occasional unintended behaviour (when the current time
plus the timeout overflows more than the current time alone).
I don't know what this code does (looks like busy waiting to me, brr;
looks like somebody needs to read up on select()), but I think I have
fixed this particular aspect. However, since I don't know how to use
this code, I have not tested it. You can find the latest version on
http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/unix/socket.fs?view=markup
and test it.
BTW, note that on every decent OS (in particular, Linux), you can use
READ-FILE READ-LINE WRITE-FILE etc. to read from and write to sockets.
An example can be found in
http://www.complang.tuwien.ac.at/forth/programs/repost.fs
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Josh Grams
> Josh Grams <jo...@qualdan.com> writes:
>>On 32-bit Linux systems, ms@ usually overflows um/mod, throwing a
>>divide-by-zero error. Replacing `um/mod` with `ud/mod drop` fixes this.
>
> No, it doesn't. The overflow is still there, but with this "fix" it
> just leads to occasional unintended behaviour (when the current time
> plus the timeout overflows more than the current time alone).
>
> I don't know what this code does (looks like busy waiting to me, brr;
> looks like somebody needs to read up on select()), but I think I have
> fixed this particular aspect. However, since I don't know how to use
> this code, I have not tested it.
Oops. Sorry, I just assumed that since it obviously had the potential
to overflow, the code using it would handle that, and that the only
problem was that it was written on a system where um/mod didn't throw an
error for overflow. I should know better than to fix the immediate
problem without looking at related code.
I wasn't using it either -- someone brought it up on #forth -- but I'll
ask him if he'll test it...
> BTW, note that on every decent OS (in particular, Linux), you can use
> READ-FILE READ-LINE WRITE-FILE etc. to read from and write to sockets.
I tend to find that annoying (except for text-based protocols where you
can use READ-LINE), because fread() blocks until you get the entire
amount you asked for (or until the connection is closed), whereas read()
returns as soon as you get some input.
I can't think of a case where it would be a show-stopper, but I prefer
to use the lower-level calls and do my own buffering in a fashion
specific to the particular protocol rather than using the generic
buffering provided by fread(). But maybe that's silly.
--Josh
Anton Ertl
>Anton Ertl wrote: <2009Dec...@mips.complang.tuwien.ac.at>
>> BTW, note that on every decent OS (in particular, Linux), you can use
>> READ-FILE READ-LINE WRITE-FILE etc. to read from and write to sockets.
>
>I tend to find that annoying (except for text-based protocols where you
>can use READ-LINE), because fread() blocks until you get the entire
>amount you asked for (or until the connection is closed), whereas read()
>returns as soon as you get some input.
Yes, a better asynchronous (i.e., non-blocking) I/O interface in Forth
could be helpful. For now, you can do it in Gforth with KEY?-FILE and
KEY-FILE, but that's cumbersome.
We use fread() because it fits with the specification of READ-FILE,
and because it is more portable than read().