Mail Archives: djgpp/1996/05/27/02:23:34
Reply to message 4146431 from FREDEX AT FCSHOM on 05/26/96 7:58AM
>That's exactly my point (perhaps I didn't explain it well enough)-- on
>DJGPP's fscanf it DOESN'T return zero, and DOESN'T exit the loop. This
>code is written (not by me--I don't even LIKe the scanf family, so I'd
>do it some other way if I were writing this piece of code) with the
>expectation that when fscanf tries to convert that MSH it'll fail
>because it's not an integer, then return zero so the inner loop will be
>exited. But on DJGPP it returns 4.
Velly odd. Can you post an exact copy of the output you get from the
program? (along with your input data, too - I have limited short-term
memory. :) It sounds to me like there's some subtle bug there but I
can't be sure w/o seeing it. Also, try cc'ing everything to the list as well
as just replying to me - somebody else might come up with some
wisdom too. :)
>On an old MSC (5.1) it behaves the same way, so I wonder if it's
>possible that this is some pre-ANSI behavior, or is it just a
>coincidence that two different implementations behave the same,
>apparently wrong, way? On later MSC's (Quick C 2.0, Visual C++ 1.5), and
>on SCO Unix, AIX and Linux it behaves as I'm wishing DJGPP did.
Hmm... there was a thread a while back that had to do with some
seemingly odd scanf() behavior from DJGPP that was related to
ANSI compliance. DJGPP _is_ ANSI compliant, but the ANSI spec
is somewhat loose in how a given implementation is required to
treat an EOF encountered in the middle of an input line, as opposed
to the beginning. This doesn't sound like your problem, but you
never know. Anybody else on the list wanna comment?
>Thanks!
Yer welcome. :)
John
- Raw text -