*scanf doesn't work properly on Mac (OS X)

[Nimrod]

I've been porting some of my code to the Mac after salvaging it from a troublesome PC.

The only problem I have now is that fscanf and sscanf don't work for parsing integers.

eg:
const char *myString = "321";
short value;
sscanf( myString, "%d", &value );

value gets set to 0, not 321. :confused:

This happens when I compile with CW7 and PB, but didn't happen on Win2k with CW7 and VC++6.

Is this a known problem? What I have to do at the moment (but it's a pain) is to have the string as "321.0" and parse it as a float, then convert it to a short later...

Thanks :-)

[sealfin]

I'm pretty sure the problem is the short type, as I had a similar problem a short while ago ...

short value;

... which for some reason can't even be scanf()'d (at least in CW and Leo) - use int instead.

[Nimrod]

Thanks, it seems to work now...

perhaps I should get round to using streams, though. The more I learn about C++ the more I despise C.

That's also what I hear from Objective-C coders about C++ :D

[OneSadCookie]

To assign to a variable of type short you need the %hd format.

Generally, don't use shorts though, unless you're in dire need of the memory... they're not as efficient as ints in general, and the small size can (and will) come back and bite you later...

GCC should give you a warning about mismatched format strings and arguments. You are compiling with -Wall, aren't you? (Note that for some bizarre reason -Wall is not the default warning setting for PB).

C++'s streams will cause you more pain than you need. Everyone who's used them eventually gets over the novelty and returns to C-style I/O. The only benefit to C++-style I/O was type-safety, and GCC type-checks C-style I/O (with -Wall), so there's really no advantage.

[Nimrod]

Thanks for the info.

Originally posted by OneSadCookie
Generally, don't use shorts though, unless you're in dire need of the memory... they're not as efficient as ints in general, and the small size can (and will) come back and bite you later...

When you talk about efficiency, is it to do with memory access being faster to 4-bit aligned values? I'd forgotten about that....

I don't tend to use ints because of their ambiguity (from platform to platform). I only use shorts where I know the values won't go too high. In the case of the above example (where I was doing that sort of that thing), the numbers don't go much higher than about 10, so even 16 bits is overkill.

But, I take your point.

I prefer the UInt16 SInt16 etc... types, but they don't seem to be standard.

BTW, I didn't know about -Wall

[OneSadCookie]

Yes, 4-byte-aligned memory accesses are (significantly) more efficient than 2-byte aligned.

short and long are just as ambiguous as int, unfortunately. Fortunately, int is (at least) 32 bits on any sensible platform ;)

int32_t and uint16_t and friends are more standard (see <stdint.h> or <inttypes.h>), but unfortunately not yet available on Windows (maybe in VS.NET?)