forums.ps2dev.org

snowsquirrel · Joined: 24 Feb 2008 Posts: 51

Why is u32 defined as an unsigned long int? I know on my 32 bit systems, a long and int are both 32. So it doesn't matter, which is used.... kind of... one really annoying side effect are the compiler warnings generated from printf.

pspZorba · Joined: 22 Sep 2007 Posts: 156 Location: NY

If I remember well:

a short is always 16bits
a long is always 32bits

and depending on the platform an int is either a short or a long

so if you want to be platform independent u32 has to be an unsigned long
not an unsigned int.
_________________
--pspZorba--
NO to K1.5 !

J.F. · Joined: 22 Feb 2004 Posts: 2906

Uh... no.

A short is 2 bytes.
An int is 2 or 4 bytes, depending on the CPU (always 4 on 32 bit or better CPUs). To be technical, a short int is 2 bytes, while a long int is 4 bytes. "int" is just shorthand for "long int" on most compilers. Note that a "long int" is NOT the same thing as a "long".
A long is 4 or 8 bytes, depending on the CPU.
A long long is 8 bytes.
A pointer is 4 or 8 bytes, depending on the CPU.

bulb · Joined: 19 Jan 2006 Posts: 50

Actually, neither is correct. The size of types in C/C++ are not fixed - the implementation is free to choose whatever size it wants. Hence the use of sizeof. This is what Java and C# "fixed". :)

I once worked with a Z80 compiler that had short defined as 1 byte (8 bits) long, and on one esoteric architecture a short was defined as 12 bits (yes, not all systems use multiples of 8 and not all systems use von Neumann architecture).

As to original poster, I think this was just arbitrary (preference of style). I also like to use long (instead of int) when I want to define 32-bit. You could switch to C++ streams and live without those warnings, because C++ Standard Library is typesafe.

snowsquirrel · Joined: 24 Feb 2008 Posts: 51

Getting o/t here, but I find streams a PITA to use, plus they tend to blow up mem usage on embedded systems.

Printf is probably the only old school technique I continue to employ. I wish they would make modernized version of of it, something like C# version of formatted strings where the format operators are not type specific. Of course that is easy in C# where everything has a toString() method.

~S

ooPo · Posted: Sat Jun 07, 2008 12:06 am Post subject:

http://en.wikipedia.org/wiki/C_variable_types_and_declarations

J.F. · Joined: 22 Feb 2004 Posts: 2906

Very true. I just described the majority of 16 / 32 / 64 bit compilers. It's rare that you'll run into anything else, so my post is the most relevant to folks here.
:)

whistler · Joined: 04 Mar 2008 Posts: 40

J.F. · Joined: 22 Feb 2004 Posts: 2906

ooPo · Posted: Sat Jun 07, 2008 10:38 am Post subject:

When it comes to C, if it isn't defined specifically in the standard then you should be very careful. That's what we call 'undefined behavior' and there's no reason to count on it being the same on every system, or even on every execution.

Usually I create a types.h file, with defines for things like uint08 and sint32. That way I can change them in one place in the code for whatever platform and compiler I end up using at any given time.

TyRaNiD · Joined: 18 Jan 2004 Posts: 918

Tbh I find that GCC's printf warnings to be somewhat overzelous, they made changes between 4.0 and 4.1 which added more petty warnings, one of them being things like the long int shit. Psplink compiled fine on 4.0.2 with all warnings, on 4.1 it spat out a fair number of format warnings. Annoys me to the extent that I tend to just turn them off, I am only really interested in ones which indicate missing parameters or mismatches %s to pointers. Anything else is generally a display issue/portability issue vs. rather than a potential crash.

hlide · Joined: 10 Sep 2006 Posts: 750

Heimdall · Joined: 10 Nov 2005 Posts: 259 Location: Netherlands

Yesterday i picked up the "The C programming language" book from K&R and it states that a int is of the same of the platform default (and atleast 16bits) and a short int (or just short) is atmost 16 bits, and a long int (or just long) is at least always 32 bits. So the newlib definition of uint32_t and int32_t are correct by defining it as a long, however if you want to be picky :) you can hack your newlib includes to your favour. I've tested rebuilding the full compiler + sdk with the -Werror flag on and there are my only changes to make int32_t and uint32_t aliased to int and not long:

stdint.h

on line 37 i replaced the original preprocessor code with:

ooPo · Posted: Sun Jun 08, 2008 2:01 am Post subject:

J.F. · Joined: 22 Feb 2004 Posts: 2906

Heimdall · Joined: 10 Nov 2005 Posts: 259 Location: Netherlands

i know its not clean, its a hack. but since the psp is 32bits it wouldn't arm to alias int32_t to int. again this is a hack that reduces lots of compiling warnings

snowsquirrel · Joined: 24 Feb 2008 Posts: 51

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

jean · Joined: 05 Jan 2008 Posts: 489

Apart from portability argumentations, sometimes even procedural coding needs some modelization :) I think of it this way: if i need a type representing a device and i know that there are <255 devices then i could (quick and dirty) choose a char; OR i could define a "device" type as a char and use it instead. Why? Because so i can define functions accepting "device" and not "char" helping me to point out inaccuracies, or (in c++) letting me redefine some operators just to make life more complex.