Re: Problem with using strings to access enum indices on Windows

[Andrew Johnson <anj@aps.anl.gov>]

Hi Mark,

On 2012-09-23 Mark Rivers wrote:
> The problem is that the " %u %n" format string does not work on Windows.
> 
> When I spoke to Andrew Johnson he said he thought this was because Windows
>  does not implement the %n format specifier.
> 
> I have done some more investigation, and found that this is not the case.
>  The problem is the leading space before the %n specifier. On Windows when
>  sscanf hits the blank space in the format specifier, but does not find a
>  blank space in the input string, it stops parsing the input string. So it
>  never reaches the %n format specifier. The GNU run-time library behaves
>  differently, it processes %n even if there is no space in the input. I
>  think it is questionable as to which is the "correct" behavior.

Your further investigation reminded to check the Known Problems page; on 
2012-01-26 I committed a change published a patch to R3.14.12.2 that removed 
both spaces from the scanf() strings in dbConvert.c and dbFastLinkConv.c.  The 
leading space in the format strings was never actually necessary, since the %u 
skips leading spaces anyway.

Note that it is essential that we check for other characters that come after 
the digits; for example consider setting the SCAN field of a record with the 
string "5 seconds".  If we don't check that sscanf() consumes the whole string 
then this could result in a 2-second scan period (there is no 's' on the end 
of the official menu strings, so the choice string would not match).  That's 
why the "%n" is an essential part of the format.  Using a "%u%n" format with 
no space could break an existing application that relies on the numeric form 
and happens to append a space or '\n' to its digits, but I thought this would 
be fairly unlikely occur in reality.

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte