Confusion! scanf() Not Behaving

[DocFlareon]

Build Environment: FS-UAE on Linux Host - Lattice/SAS C (5.10 on WB 1.3, 6.5 on WB 3.1)

I'm building an RPG Character Assistant app, and I've come into an issue when I attempt to build and run on both WB1.3 and 3.1 scanf() is not writing data into variables. I wrote a simple program to test.

#include <stdio.h>
#include <stdlib.h>
unsigned short int a;
unsigned short int b;
unsigned short int c;

void main()
{
printf("A is?");
scanf("%d", &a);
printf("B is?");
scanf("%d", &b);
c=a+b;
printf("%d + %d is. . . %d!", a, b, c);
return;
}

When I execute the program, all three variables have the value 0, not matter what numbers that I enter for 'a' and 'b' when prompted. I am quite confused, because this code runs just fine when gcc builds it on the host Linux machine.

scanf() can't be this broken in Lattice C, and I don't see how running inside an emulated environment would make any difference.

[StingRay]

Try changing "unsigned short int" to "unsigned int". Any difference?

[alkis]

either what StingRay suggested or change the %d in scanfs to %hu (and hope SAS C supports it)

[DocFlareon]

Originally Posted by StingRay

Try changing "unsigned short int" to "unsigned int". Any difference?

That is the dumbest thing I ever heard. . .
(changes code and builds it)
(watches it behave properly)
Uhmm, Okay then! It's stupid, but it works. So what if I waste a few bytes creating too-large variables, at least it behaves now.

(directed at the 30yr-old compiler suite that is stupid)

[a/b]

When you are writing multi-platform software you should generally be careful when using built-in types like int. Int can be 16, 32, or 64 bit depending on platform and OS. Use int16_t, int32_t, uint32_t etc. instead (or if you are using an archaic compiler that doesn't have those you can define yours with typedef). Of course, if depends what kind of software you are writing...

Now to your example, pretty much reiterating what's been said...
You are mixing up 16 and 32 bit code, as well as signed and unsigned code. Your variables are unsigned 16 bit and %d in printf/scanf is signed 32 bit.
Either use %hu (short unsigned) or defined them as int (and if you them as unsigned int then use %u).

If your Linux box is running on x86/x64, which is little endian, then the code will work because printf/scanf will store the lower word correctly. If you enter numbers higher than 65535 then you will get a non-zero result on m68k (but still incorrect).

[phx]

Originally Posted by DocFlareon

I am quite confused, because this code runs just fine when gcc builds it on the host Linux machine.

You were just lucky, because your Linux machine is probably a little-endian architecture.

"%d" means that scanf() expects a decimal number and writes it into an "int" variable, which has usually 32 bits on the Amiga. Better compilers would check that the type matches the format string and warn you otherwise.

What happens is that scanf() writes your input to this 32-bit (4 bytes) field the given pointer is pointing to. Provided your input was between 0 and 65535 the first two bytes stay zero.

As you were using 16-bit "unsigned short" variables, not "int", the first input sets "a" to zero and "b" to your entered value. The second input sets "b" to zero and "c" to your entered value. In the last step you reset also "c" to zero by adding "a" and "b".

On the other hand, when writing a 32-bit "int" in little-endian format the bytes are written in reverse order, which means the first byte is the least significant byte, and you can see your input.

But in all cases you are overwriting the following memory space, which can cause hard to track down bugs.

[DocFlareon]

Ahh! This is my first experience where endianess would cause issues. The more you know. . . Moral here is "Don't get sloppy with data types, or strange things will happen."

[alkis]

Or, you know, read the docs

[Thorham]

Originally Posted by DocFlareon

(directed at the 30yr-old compiler suite that is stupid)

Blaming an old compiler like Latice for not supporting newer things, or not behaving like you're used to is just plain silly

[alkis]

I did actually checked. Even though its 30 years old compiler it does support %hu in scanf.
Compiler works as it should and according to standard.

It's user (or developer if you will) error.