Re: Bug in scanf?

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 09.12.2025 um 09:27 schrieb Anders Magnusson:
> Morning,
> 
> Den 2025-12-09 kl. 03:49, skrev Robert Elz:
>>      Date:        Mon, 8 Dec 2025 20:45:00 +0100
>>      From:        Anders Magnusson<ragge%tethuvudet.se@localhost>
>>      Message-ID:<ffd8ba3e-ec94-4583-a431-13a5d7c88a2c%tethuvudet.se@localhost>
>>
>>    | I just stumbled over something which may be a bug in scanf()...?
>>    | This example is in C99 7.19.6.2 clause 20.
>>
>> Yes, but nowhere there does it say what the result should be in the
>> case that you give, and I think you're arriving at an incorrect
>> conclusion.
> Sorry, but I think that is very clear?  The input scanning should stop 
> whenever something unwanted is read.
> And as you noticed in the followup mail; this was an example from the 
> standard which was what I was referring to :-)
> 
> Also, as you note it should accept whatever strtod() do, _but_: C99 note 
> 242 (C23 note 348) says:
> 
> "fscanf pushes back at most one input character onto the input stream. 
> Therefore, some sequences
> that are acceptable to strtod, strtol, etc., are unacceptable to fscanf.".
> 
> which is what should happen here (and the reason "100ergs" should fail 
> for %f in *scanf()).
> When reading the 'r' the scanning for %f fails and it returns.  As the 
> standard says...?

That's exactly the reasoning I had in mind. I wonder though why fscanf
is _required_ to reject this sequence, instead of allowing an
implementation with a larger pushback buffer to accept this string, thus
making this decision a quality-of-implementation issue. The C99
rationale doesn't mention this particular possibility.

Roland