This is the mail archive of the
mailing list for the GCC project.
Re: IP ADDRESS OF MACHINE
- From: John Love-Jensen <eljay at adobe dot com>
- To: Nelson Guedes Paulo Junior <npaulo at linux dot ime dot usp dot br>
- Cc: "Andrea 'Fyre Wyzard' Bocci" <fwyzard at inwind dot it>, snodx at hotmail dot com, gcc-help at gcc dot gnu dot org
- Date: Fri, 01 Mar 2002 08:36:21 -0600
- Subject: Re: IP ADDRESS OF MACHINE
- References: <Pine.LNX.firstname.lastname@example.org>
>If you put a cast to (unsigned char) in fornt of some (*entry) you get
the correct results too, but why in [his] machine this works whitout any
I assume a "%hhu" is supposed to be a 8-bit unsigned, a C extension in some
(but not all) libraries.
>Is this a portable solution?
*heh* Depends what you consider "portable".
C and C++ don't support the notion of canonical data types. Such as "int32"
or "nat8". (In FORTRAN, you can do INTEGER*1 or INTEGER*4 or somesuch to
specify explicitly the size.)
Besides, you never know if the canonical data type "int32" is supposed to be
big-endian (Blefuscu style) or little-endian (Lilliput style). Or in some
cases, something even more exotic. Sometimes call UNIX style (big-endian,
also known as Motorola style), XINU style (little-endian, also known as Intel
style) ... plus NUXI style and IXUN style. Oh dread!
Oh how I wish I could say:
typedef (7 ... 86) range_t
range_t i; // A variable that can span 7 through 86, inclusive.
But alas. I digress.
I also wish I could do...
explicit typedef int xcoord_t;
explicit typedef int ycoord_t;
And then do things like this...
void Foo(xcoord_t x);
void Foo(ycoord_t y);
...and xcoord_t and ycoord_t wouldn't be mere aliases to int, but distinct
But alas. I digress again.
To answer you question: nope, commonly, C/C++ programs are not portable.
Many programs assume IPL32, but many new hardware platforms are PL64/I32.
And older hardware might be L32/IP16, or L32/I16/P20(32). The I stands for
integer size, the P for pointer size, the L for long integer size.
To write a C/C++ program that is portable, you have to take meticulous care.
You cannot cavalier cast things from one thing into another, You cannot make
assumptions about byte-ordering. Or type sizes. Or if integers are
represented in 2's complement or 1's complement ... or even BCD (I suppose).
You cannot rely upon OS API facilities (no GDI calls in Windows, no Quartz
calls in Mac OS X, no X11 calls) ... unless you are committed to that
technology, and thus limiting portability. If a routine calls for a
"size_t", use a "size_t", don't use an "int". Oh, the list goes on and on.
The more assumptions you make, the less portable your code.
My code compiles (and sometimes runs...) on several platforms, so I get to
experience the joys of agnostic C++ coding every day.
If platform independence in important for you, I recommend Java, Ada, or
LISP. Or if you're weird, Squeak.
Otherwise, if C or C++ is your poison of choice, strive to write code that is
platform agnostic. For any OS API calls, create a Operating System
Abstraction Layer that insulates your program from platform dependencies. It
is possible, albeit strife with landmines. GNU suite of tools is a case in
point. Angband is another.