From: j DOT aldrich6 AT genie DOT com
Message-Id: <199605270553.AA269296409@relay1.geis.com>
Date: Mon, 27 May 96 05:33:00 UTC 0000
To: fredex AT fcshome DOT stoneham DOT ma DOT us
Cc: djgpp AT delorie DOT com
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: djgpp 2.0 fscanf bug??

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