Bug 000221

When Created: 05/18/1998 08:57:19
Against DJGPP version: 2.01
By whom:
Abstract: scanf sometimes incorrectly matches %*s
I'm using DJGPP 2 and gcc/gpp &libs 2.8.1

Problem example :

int	checkpoint1;
int	checkpoint2;
int	items;
char	junk[256];

checkpoint1 = -1;
checkpoint2 = -1;
items = sscanf("blah ", "blah%n %s%n", &checkpoint1, junk, &checkpoint2);
printf("items=%d cp1=%d cp2=%d\n", items, checkpoint1, checkpoint2);
items = sscanf("blah ", "blah%n %*s%n", &checkpoint1, &checkpoint2);
printf("items=%d cp1=%d cp2=%d\n", items, checkpoint1, checkpoint2);

Output :

items=-1 cp1=4 cp2=-1
items=0 cp1=4 cp2=5

The first scanf correctly says that %s doesn't match, and so
correctly doesn't assign checkpoint2.

The second however (only difference is '%*s' instead of '%s',
result should obviously be the same) incorrectly matches %s
and assigns checkpoint2.

Workaround added: 05/18/1998 08:58:17
By whom:
Don't use %*s for the time being ...

Note added: 05/19/1998 11:45:57
By whom:
I was doubtful wether this really is a misbehaviour, even after re-reading
the relevant part of the C Standard. But on cross-checking this behaviour
on Linux and DEC Unix, it seems this actually is a bug (both report the
same values for items, cp1 and cp2 with %s and %*s). But that kind of 
argument is hearsay, at best, so let's see what the real story is...

If memory serves, we left this point unhandled at the time we last 
revised the *scanf family implementation, because none of us was brave
enough to claim to have understood that part of the standard:  does a
"%n" directive after a failed matching which itself was caused by empty 
input trigger the mechanism that makes a 'matching failure' into an 'input
failure', or not? That is the question. If not, then '%n' should probably
be executed cleanly in that situation, and only the next format spec, if any,
should trigger EOF being returned (i.e. flag 'input failure'). 

Note added: 04/18/1999 10:00:15
By whom:
I cannot reproduce this problem with v2.02: I get these outputs:

  items=-1 cp1=4 cp2=-1
  items=0 cp1=4 cp2=-1

which are the correct results.

So either this was solved since v2.01, or this is another case of
damage done by over-zealous optimizations of a smartass known as
GCC 2.8.1.  In either case, this is no longer an outstanding DJGPP

I'm closing this report.

Closed on 04/18/1999 10:00:09: Not a DJGPP bug (and doesn't exist in v2.02 with GCC
By whom:

  webmaster     delorie software   privacy  
  Copyright 2010   by DJ Delorie     Updated Jul 2010