Re: GCC difference in size of 'long int' on Suse SLES9 / Suse Professional 10.0

Toni Erdmann wrote:

Hello *,

I have a problem compiling an application for 2 different platforms:

1.) Dual Opteron SUN V20z with Suse Professional 10.0
2.) Dual XEON FSC RX200 with SLES 9

I seems to me that the size of a 'long int' is

1.) 4 bytes
2.) 8 bytes

which makes it difficult to have one executable for both
systems.

I did not find an option for 'gcc' (on x86) to force a length
of 8 bytes.

- is it simply the "#define __WORDSIZE .." definition in
/usr/include/bits/wordsize.h?

- are there other dependencies (libc interfaces)?

- at least, do I have to compile two executables, one for
each platform?

- application is sar/sadc of sysstat which reads some
information from /proc/... files into internal structures.
The kernel uses printf() with 'long int', sadc uses
sscanf() ro read it into 'long int'.
For values > 2**32 this does not work correctly,
when the kernel uses 8 bytes 'long int' and sadc uses
4 bytes 'long int'.

- I can't use the installed sysstat package (version < 5.1.5),
because this one has a bug on SMPs. I must not install a
newer package version. I use the 2 binaries of 7.0.0 in a
private directory.

- I can't compile 'on-the-fly'. 'gcc' might not be installed.

- using '__uint64_t' instead of 'unsigned long int' would be the
best, but this would take too much time. I will contact the
maintainer for this issue.

Thanks for any hints,
Toni

P.S.: re-post because of typo in "alst.os.linux.suse"
^

It would be poor software if you have to change a globally used .h file in
order to compile it. What will happen with the next piece of software you
fancy trying from a source? Concider yourself told off and punish yourself
with one less Mars bar this week. (I'm a programmer, I know how important
Mars bars are).

It is usual to compile for the hardware, otherwise you run the risk of
clashing with the hardware and any libs that you interact with. In reverse,
if you compiled for 8bit ints then try to run on a machine with 4bit
natural ints, then you have data loss problems to concider. You are also
likely to hit boundary problems in arrays or volatiles. A system state
error signal caused by a single misplaced int is particularly hard to find.

But you have macros to restrain the size of the data type. So if your own
software needs the int to be a certain size, then you have the macros
INT_TYPE_SIZE and others for simmilar data type resizing. You can specify
the macros to use for your project as directives or in a file for use with
make. You can also specify the architecture of the target.

It is important though to concider carefully any of your ints that are used
in interaction with the OS and hardware that it is running on.

For this reason you will often see programmers who have to work on many
platform types build up their own int types. Just by wrapping your ints
inside a class where you specify the size, possibly on the fly. If you do a
quick 'c++ integer class' search you will find examples, some of them
complete classes.

But still, you should compile for the hardware and OS your software is
running on. If your machines are in touch with each other, then updating
the source across an rsync isn't hard, I have even done it before where
outstations checked nightly with a make dummy run to see if they are
changes, then re-makes the utility if necessary. .

So the answer is, if your software needs the int to be a certain size,
either carefully use one of the macros such as INT_TYPE_SIZE, or more
safely use an int class where you can specify the size used as the
datatype, this is more flexible because you can have anything from a nibble
to 2millionT byte integer (ok, touch of exageration there, but I'm sure I
saw a class of this type some time ago that claimed to be unlimited), but
in all cases compile for the target hardware.

By the way, if you are using one of the GUI's then each one already has
this, for example qt has the Q_INT{size_in_bits}, you can simply treat it
as a datatype and know that it will be correct on each architecture,
provided your software is compiled for that architecture too.

.

Relevant Pages

  • Re: Im a C++ programmer, and Relfs X.CPP is good.
    ... >> and it doesn't compile either. ... home.cpp:93: implicit declaration of function `int fclose' ... You cannot change to your home directory through an external ...
    (comp.lang.lisp)
  • Re: Im a C++ programmer, and Relfs X.CPP is good.
    ... >> and it doesn't compile either. ... home.cpp:93: implicit declaration of function `int fclose' ... You cannot change to your home directory through an external ...
    (comp.unix.programmer)
  • Re: new order doubt
    ... Warning test2.c: 8 no type specified. ... Defaulting to int ... Tests probably come in several different types: this should compile ... Even Microsoft has problems with this obscure rules. ...
    (comp.lang.c)
  • Re: non-static context
    ... public MyStatic(int length, int width) { ... Within the MyStatic constructor method, a local variable named area is ... This version of class MyStatic won't compile. ...
    (comp.lang.java.help)
  • Re: Newbie help with C++
    ... On what platform did ... > pice of code ... > int main ... > When I compile and run the program i get this ...
    (alt.comp.lang.learn.c-cpp)