C code portability question

[Chuck(G)]

Of course, you also need endian-consistent types as well for portability...

Oh yeah, I've been bit by that one many times. As has any early Unix port developer.

 

[dhau]

On same platform you can get vastly different code generation from different C compiler vendors. Best way to check out quality is to use C to ASM translation if its supported.

 

[alank2]

I am totally reversing my earlier opinion about using stdint.h and _t variables.

The reason is that is that the DOS and WIN32 compilers I use already have non *_t types that are consistent. Sure int isn't consistent, but essentially I moved to this strategy:

if a variable _has_ to be 32-bit AND used in DOS, use long
if a variable _has_ to be 16-bit AND used in WIN32, use short
else just use int

 

[Chuck(G)]

What do you do when you're crossing platforms (non-x86); forget about operating systems?

 

[alank2]

What it came down to for me is that as much as I like the consistency of forcing the compiler to use something, it probably isn't ideal to make it use a short all the time if its compiling for 32-bit. I first started with the approach of, if it doesn't matter I'll just use int and I'll leave uint16_t and uint32_t for when I want to force it one way under both 16-bit/32-bit. That worked. Then I thought why use stdint.h at all, I can always use short or long to force an exact size if I need to with both DOS/WIN32.

I agree with you though that outside of that, stdint.h and _t vars make sense and could be a good thing. I guess defining the scope of what you intend some code to support from the beginning helps.

 

[Chuck(G)]

I move between OS platforms and architectures quite a bit. If I write a bit of code, I'd like to know that it can run under, say, AMD64, x86 and ARM. So my coding style reflects that.

 

[daver2]

I always try to use my OWN types in my OWN programs and have a little 'portability' file where I put all of the type equating and any other conversion issues (e.g. endian manipulation).

We used to develop software for a Win32 platform only at work. However, this adopted strategy, won us a few major software contracts because the customer wanted our software porting to SGI IRIX. A couple of days later we had a largely working and debugged system... Had we not written the software in this manner to start with, it would have been a major undertaking.

Dave

 

[Svenska]

When I was looking at getting the Arachne web browser working in Linux again, I noticed that there is no universal 32-bit type available for both 16 and 64 bit compiles: "int" is either 16 or 32 bit, and "long" is either 32 or 64 bit. (For Arachne specifically, this causes font rendering to break.)

So stdint.h is definitely the way to go if you want portable code across a wide range.

 

[BloodyCactus]

I always use stdint.h + inttypes.h and size_t. it gets annoying when you dump say an ftell() into a uint32_t and its good on a few platforms then and one says noo i need size_t for that..

 

[Makefile]

I always use stdint.h + inttypes.h and size_t. it gets annoying when you dump say an ftell() into a uint32_t and its good on a few platforms then and one says noo i need size_t for that..

And even then there's off_t (which unlike stdint.h I think is POSIX only) since file offsets become 64 bits even on 32-bit pointer architectures.