This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
sscanf behaviour. bug?
- From: Hannes Krueger <Hannes dot Krueger at uibk dot ac dot at>
- To: newlib at sources dot redhat dot com
- Date: Thu, 20 Mar 2003 14:45:07 +0100
- Subject: sscanf behaviour. bug?
The following is from a recent thread on comp.lang.c
and seems to be a bug in the sscanf implementation of newlib, since cygwin (with
which this behaviour occurs) is using newlib.
I had a look in the newlib-sources, but I wasnt able to locate this problem.
Maybe someone else is able to?!
regards
Hannes
the following is copied from the newsgroup:
---
In <3e703aa8$1 at sia dot uibk dot ac dot at> student <student at dont dot like dot spam> writes:
>>I encountered some strange sscanf-behaviour.
>>
>>this is the line I want to parse:
>>B0927035313520....
>>
>>I want to read fixed columns.
>>
>>sscanf(line, "%*c%2lf%2lf%2lf ...." , &val1, &val2, &val3 ....
>>
>>when I compile in a linux gnu environment I get
>>val1 = 9
>>val2 = 27
>>val3 = 3
This is the correct behaviour. %f (or any other conversion descriptor,
for that matter) does not allow the suppression of zeros before the
start of the conversion.
>>But when I compile under cygwin (gcc 3.2) on windows I get
>>val1 = 92
>>val2 = 70
>>val3 = 35
This is broken behaviour. You have specified a *maximum* field length
of 2, but the first conversion used 3 characters.
>>It seems that the second one omits the zeros
>>
>>Is this some weird gnu - non-gnu diffence? something I missed in the
>>documentation.
>>Any suggestions what to do aboout that?
Get a non-broken implementation. If this is not an option, use %2s
instead and convert the strings to double with
(val[0] - '0') * 10.0 + val[1] - '0'.
If needed, you can also check the validity of the strings with
isdigit((unsigned char)val[0]) && isdigit((unsigned char)val[1])
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan dot Pop at ifh dot de