Killertechno
Posts: 180
Joined: Wed Jan 02, 2013 8:28 am

[C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 9:12 am

Hi to all, I have little doubt about compatibility between 32/64 bit OSs.....

C data types size in bytes (e.g. for long) could be different, so I should tell compiler to compile in 32bit even if running on 64bit OS.
If I've correctly understood, I just need to use "-m32" option in compiler string.

Ok, it sounds enough easy, but does this MUST work for Raspberry, or is there any exception?

User avatar
PeterO
Posts: 5071
Joined: Sun Jul 22, 2012 4:14 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 9:29 am

Looking at https://gcc.gnu.org/onlinedocs/gcc/Opti ... p_letter-M it's not clearr that -m32 is even a valid switch on ARM architectures.

Easiest thing to do is give it a try and see what "sizeof" returns for various C types.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
PeterO
Posts: 5071
Joined: Sun Jul 22, 2012 4:14 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 9:42 am

So now I'm sat in front of a PI !

Code: Select all

[email protected]:~ $ gcc -m32 -o test test.c
gcc: error: unrecognized command line option ‘-m32’
[email protected]:~ $ 
One solution is to include stdint.h and use the explicit sized types such as int32_t in your code.
PeterO
Last edited by PeterO on Wed Feb 13, 2019 9:50 am, edited 1 time in total.
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Heater
Posts: 13627
Joined: Tue Jul 17, 2012 3:02 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 9:44 am

If the size of your types matters than do not use the C type, char, int etc, instead use the fixed width types:

int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t

char is an interesting case because C does not define if it is signed or not. Even more reason to use int8_t and uint8_t.

There are more such types. You can read about them here:
http://pubs.opengroup.org/onlinepubs/96 ... int.h.html
https://www.gnu.org/software/libc/manua ... egers.html
https://en.cppreference.com/w/cpp/types/integer

Some/most are now part of standard C others are GCC extensions. Even if they are not C standard you should use them, if you move your code to a machine that does not define them you can always define them yourself.

These types are defined in <stdint.h> for C and <cstdint> for C++.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 4767
Joined: Wed Feb 04, 2015 6:38 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 9:54 am

Its a little messy.
Its better to include "inttypes.h" (which itself includes stdint.h)
inttypes.h adds some more useful stuff such as the printf formats.
Killertechno wrote:
Wed Feb 13, 2019 9:12 am
Hi to all, I have little doubt about compatibility between 32/64 bit OSs.....
If you use the exact width types people have posted above, there are no compatibility issues at all.
Use the same code for 32 and 64 bits, Intel or ARM.
Heater wrote:
Wed Feb 13, 2019 9:44 am
char is an interesting case because C does not define if it is signed or not. Even more reason to use int8_t and uint8_t.
POSIX mandates that CHAR_BIT is always 8, so size should not be an issue.

char is signed on Intel and unsigned on ARM (the Pi). You cannot explicitly use "signed char" or "unsigned char" which, though legal types, are both distinct from the "char" type that library functions expect. The only option if the type of char is important (which it often is) is to use the "-funsigned-char" compiler option. All C compilers have similar options. "uint8_t" etc will fail when library functions are used.

If you don't like all the "_t" things you can add your own types of course:

Code: Select all

typedef uint8_t  byte;
typedef uint16_t word;
typedef uint32_t dword;
typedef uint64_t qword;
typedef int8_t   int8;
typedef int16_t  int16;
typedef int32_t  int32;
typedef int64_t  int64;
typedef double   real;

Heater
Posts: 13627
Joined: Tue Jul 17, 2012 3:02 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 10:40 am

Ha!, I have never even heard of CHAR_BIT.

Anyway the C standard only specifies a minimum width of char so better to be explicit in all cases. I like consistency.

If this seems "messy" and confusing then you have understood correctly. There are very good arguments for not using C/C++ because of all this chaos, and much other undefined behavior and chaos besides. You might consider using some other language that is rather more logical, consistent and strict about all this, like Ada, Rust or D, for example. The suggestion is that you are much less likely to run into surprises and make mistakes in such languages.
Memory in C++ is a leaky abstraction .

Heater
Posts: 13627
Joined: Tue Jul 17, 2012 3:02 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 10:49 am

Oh boy. Personally I hate to see word, dword, qword, etc defined.

Traditionally "word size" referred to the width of the registers and memory of the machine itself. Could be 4, 8, 16, 32, 64, 128 bits and there have been a variety of machines with word sizes between those.

In short "word" etc don't actually tell the reader anything.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 4767
Joined: Wed Feb 04, 2015 6:38 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 11:24 am

Heater wrote:
Wed Feb 13, 2019 10:49 am
Oh boy. Personally I hate to see word, dword, qword, etc defined.

Traditionally "word size" referred to the width of the registers and memory of the machine itself. Could be 4, 8, 16, 32, 64, 128 bits and there have been a variety of machines with word sizes between those.

In short "word" etc don't actually tell the reader anything.
What would you choose instead?

word/16, dword/32, qword/64 are the Intel "standards".

D has "byte", "short", "int", and "long" defined and fixed at 8, 16, 32, 64 bits.
But D doesn't have 47 years of history behind it!
In C, you cannot define short as a type of course, but you can do ...

#define short int16_t
#define int int32_t
#define long int64_t

but I don't like it.
Last edited by jahboater on Wed Feb 13, 2019 11:26 am, edited 1 time in total.

User avatar
rpdom
Posts: 15397
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 11:26 am

Heater wrote:
Wed Feb 13, 2019 10:49 am
Oh boy. Personally I hate to see word, dword, qword, etc defined.

Traditionally "word size" referred to the width of the registers and memory of the machine itself. Could be 4, 8, 16, 32, 64, 128 bits and there have been a variety of machines with word sizes between those.

In short "word" etc don't actually tell the reader anything.
Indeed, as mentioned in the original K&R book.

I have worked on a system with 6 or 9 bit bytes and 18 or 36 bit words.

jahboater
Posts: 4767
Joined: Wed Feb 04, 2015 6:38 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 11:30 am

rpdom wrote:
Wed Feb 13, 2019 11:26 am
I have worked on a system with 6 or 9 bit bytes and 18 or 36 bit words.
So have I (Honeywell mainframes, Control-data super computers, DEC 10).

But I don't see the need to worry about it now, probably only of interest if you work in a museum.

The IEEE (POSIX) in 2008 fixed CHAR_BIT at 8, and thats good enough for me!
(maybe because there is no known hardware with bytes other than 8-bits, much like signed integer overflow is becoming defined and accepted because there is no known integer hardware that is not twos-complement. The world moves on.)

As for word/dword/qword, its just an example, choose what you like.
I use the convention "word = 16" bits only because its standard on Intel and very common (even though the "wordsize" could be said to be 64-bits).
Here is intels "convert" instruction:

CBW/CWDE/CDQE—Convert Byte to Word/Convert Word to Doubleword/Convert Doubleword to Quadword

Everyone knows what Intel mean here.

User avatar
rpdom
Posts: 15397
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 12:10 pm

jahboater wrote:
Wed Feb 13, 2019 11:30 am
rpdom wrote:
Wed Feb 13, 2019 11:26 am
I have worked on a system with 6 or 9 bit bytes and 18 or 36 bit words.
So have I (Honeywell mainframes, Control-data super computers, DEC 10).
Some of them are still in use. Not that I work with them nowadays. It's been over ten years since I used the 36 bit systems, although towards the end the huge mainframes were replaced with software and hardware emulation on a series of small Unix boxes. One ran the main code, another handled tape drives, another for comms and others for printing.

jahboater
Posts: 4767
Joined: Wed Feb 04, 2015 6:38 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 12:21 pm

rpdom wrote:
Wed Feb 13, 2019 12:10 pm
Some of them are still in use. Not that I work with them nowadays. It's been over ten years since I used the 36 bit systems, although towards the end the huge mainframes were replaced with software and hardware emulation on a series of small Unix boxes. One ran the main code, another handled tape drives, another for comms and others for printing.
Interesting. I last used a 36 bit machine in about 1980 or so. The 36-bit word held six 6-bit characters, upper case only. For some time afterwards linker's only expected that external symbols be unique in the first 6 characters and one case, I presume because for speed they just matched with integer registers.

User avatar
rpdom
Posts: 15397
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 12:43 pm

jahboater wrote:
Wed Feb 13, 2019 12:21 pm
Interesting. I last used a 36 bit machine in about 1980 or so. The 36-bit word held six 6-bit characters, upper case only. For some time afterwards linker's only expected that external symbols be unique in the first 6 characters and one case, I presume because for speed they just matched with integer registers.
Yep, Bull (previously Honeywell) systems. They used 36 bit words with 6x6 bit bytes or 4x9 bit bytes. The emulated systems were still in use for a few years after I left that job in 2006.

Heater
Posts: 13627
Joined: Tue Jul 17, 2012 3:02 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 3:26 pm

jahboater,

Yes, of course Intel use "CBW/CWDE/CDQE—Convert Byte to Word/Convert Word to Doubleword/Convert Doubleword to Quadword". They are descriptive of what Intel's processors do in actual instructions. We had BYTE, WORD, DWORD in PL/M back in the day.

Low level, processor specific. Does not really have any place in a high level language that could end up running on all manner of machines with different word sizes. Should we also have "NEAR" and "FAR" pointers as x86 required?
D has "byte", "short", "int", and "long" defined and fixed at 8, 16, 32, 64 bits.
But D doesn't have 47 years of history behind it!
Certainly D does have decades of history behind it. It was inspired by C and devised by the guy that wrote the first actual C++ compiler as well as writing a C compiler befor that.

Actually I was looking at D's basic types today and a bit sad to see they follow C. It's good their size is actually specified though.
Memory in C++ is a leaky abstraction .

swampdog
Posts: 245
Joined: Fri Dec 04, 2015 11:22 am

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 8:25 pm

As I'm here I'll stick my oar in and say not to worry about it unless it becomes a problem. Three areas..

(1) Overflow in the sense you need a larger number range.
(2) Storage in that you've run out.
(3) Hardware, talking to it.

..and it's only (3) where you must know. (1) and (2) causing problems is more likely a design flaw - eg:

something foo[BAR];
/*unsigned*/ int i;
for (i=0; i< BAR; i++) foo[ i ];

If it works for 32bit it'll work on 64bit so why complicate matters by using (say) "uint64" which is likely to incur performance side-effects - another headache you don't need.

Just for the fun of it, here's a migraine..

Code: Select all

#include <stdio.h>
#include <limits.h>

int
main()
{float f=-1;
 double d=-2;
 long long l=-3;
 int	x[2];

 printf("%u %u %u %u\n",sizeof f, sizeof d, sizeof l,sizeof x);

 *(double*)x = f;
 d = *(double*)x;
 *(long long*)x = l;

 printf("%g %lld %x %x\n",d,*(long long*)x,x[0],x[1]);

 x[1] ^= 0x80000000L;
 x[0] += 2;

 printf("%lld %x %x %llx\n",*(long long*)x,x[0],x[1],LLONG_MAX);

 return 0;
}
..and critics say C is nothing more than a glorified assembler. Show me the evidence I say! :-)

Heater
Posts: 13627
Joined: Tue Jul 17, 2012 3:02 pm

Re: [C] compatibility data types 32-64 bit?

Wed Feb 13, 2019 9:26 pm

...not to worry about it unless it becomes a problem.
It's that attitude that causes us to have endless problems where people have not thought these things through. C has a ton of undefined behaviors that perhaps don't matter and never show up for a developer on his machine, his OS, his compiler and his usage. That leaves his code full of traps that are going to cause bugs and security issues for others who take on the code in different environments.

Spend some time porting big projects from one hardware, OS, compiler to another or creating cross platform software and you soon become painfully aware of all this.
...critics say C is nothing more than a glorified assembler...
So they do. Like you I disagree. Especially with modern optimizers that will transform you code into something most assembler developers would never have guessed at. And, more obviously, it is cross-platform after all.

However it looks to me like C has about the minimum feature set required of a high level language to abstract the features of a typical machine and enable creating cross platform code. That is after all what it was designed for, moving Unix from assembler to an HLL so as to make it portable.

I guess it depends on ones perspective, are you an assembler programmer looking up or a Haskell programmer looking down? For example.
Memory in C++ is a leaky abstraction .

swampdog
Posts: 245
Joined: Fri Dec 04, 2015 11:22 am

Re: [C] compatibility data types 32-64 bit?

Thu Feb 14, 2019 2:49 pm

Spend some time porting big projects from one hardware, OS, compiler to another or creating cross platform software and you soon become painfully aware of all this.
You assume too much sir!

Ibm Aix 5 upward.
Redhat 4 upward.
Sles 9 upward.

You'll be aware all the above in earlier versions came in 32bit and 64bit variants and the latter two are additionally available for PowerPC. I wrote some security auditing software which had to work on all variants of the above resulting (iirc) in 14 different rpm's and lpp's (aix rpms) all from the same source code which I got to write single handed. The company I wrote it for got bought out by a well known anti-virus company.

Never had to worry about data sizes. Correct design strives to make that a non-problem and where it must be handled, wrap it up in something portable so it only has to changed in one place. Admittedly, it was in C++ (so easier), and even when I call C routines which require memory they're wrapped in objects which in turn utilise a raw memory allocator. eg:

sdMem<char> p(size);

..deallocates itself and the typedef "sdSiz" equates to size_t and can do double duty in for() loops. That's how you make it a non-problem.
I guess it depends on ones perspective, are you an assembler programmer looking up or a Haskell programmer looking down? For example.
I evolved. I used assembler initially (through necessity). I couldn't forget Cobol fast enough and Pascal wasn't portable because you had to use incompatible non standard versions to get anything done then K&R C hit the scene. "while (*d++ = *s++);" is a vast improvement on writing the asm because it's portable. However, when C++ arrived it's even better to write "d=s" rather than "strcpy(d,s)" because no need to worry about the storage.

Heater
Posts: 13627
Joined: Tue Jul 17, 2012 3:02 pm

Re: [C] compatibility data types 32-64 bit?

Thu Feb 14, 2019 4:18 pm

swampdog,
You assume too much sir!
Seems I do. My apologies.

Which leaves me wondering how we could come to different conclusions about the safety of C/C++ and pitfalls of cross-platform code.

A lot of my experience has been moving embedded applications around different architectures/operating systems. Motorola 68000, PowerPC, ARM, x86. 16, 32 and 64 bit. Linux, PSOS, VxWorks etc. All kind of compilers from different vendors.

All manner of problems with that. Many due to the language and it's undefined behaviors. The size of types, signedness, structure layout, endianness...

Not to mention the plain old bugs one uncovers when porting code around, buffer overruns, dangling pointers, memory leaks in C++ etc, etc.

I have not kept up with RedHat since using their CD boxed set in 1997 or so but other distros have certainly had these issues. One case that sticks in my mind was creating SSL certificated on Debian a few years back. Worked on 64 bit Debian, failed on 32 bit. Turned out I was asking for expiry dates after 2038 and the 32 bit version rolled time over, thus creating pre-expired certs!

As you say "Correct design strives to make that a non-problem...". I agree. But I put the emphasis on "strives" because it fails so often. It also requires meticulous attention to detail when coding and even then it's wise to use static analysis tools, modern dynamic analysis tools and a huge amount of testing. These problems permeate the whole code base and cannot be isolated in some abstraction layer.

We only have to watch the security exploit notifications arriving everyday to see how bad things are.
Memory in C++ is a leaky abstraction .

swampdog
Posts: 245
Joined: Fri Dec 04, 2015 11:22 am

Re: [C] compatibility data types 32-64 bit?

Sat Feb 23, 2019 12:15 am

Heater,
Which leaves me wondering how we could come to different conclusions about the safety of C/C++ and pitfalls of cross-platform code.
We diverged because we forgot my (3) point. I'm not talking directly to (3) hardware whereas you are in which case I'd likely be be doing the same as yourself because there's rarely enough resources in embedded to abstract enough for the exercise to be useful and even less spare grunt.
A lot of my experience has been moving embedded applications around different architectures/operating systems. Motorola 68000, PowerPC, ARM, x86. 16, 32 and 64 bit. Linux, PSOS, VxWorks etc. All kind of compilers from different vendors.

All manner of problems with that. Many due to the language and it's undefined behaviors. The size of types, signedness, structure layout, endianness...
It's why (imo) it's best to be comfortable with the language first. When one *knows* what one writes *must* do a certain thing but it doesn't you'll follow the correct debugging path whereas if there's the slightest doubt it's a brick wall.
Not to mention the plain old bugs one uncovers when porting code around, buffer overruns, dangling pointers, memory leaks in C++ etc, etc.
Also bad data sheets masking bugs. First time I ever got bitten by that I was hammering away at (I *think* it was the DMA chip) on the Atari ST - I was trying to access its "scsi" bus somehow. The sketchy docs stated something along the lines of having to transfer in 16 byte/word chunks but it would randomly corrupt or hang. Turned out it one particular circumstance you'd have to transfer one more chunk if it had returned an error. That was the reason for the sketchy doc - buggy chip design. Stood me in good stead later though back in the dark days of having to wade through M$ winapi docs where'd you'd get a gut feeling by the way something was worded that there was a hidden feature waiting in there.

Return to “C/C++”