21 Sep
1998
21 Sep
'98
5:47 a.m.
It was thus said that the Great Allison J Parent once stated:
< As a software geek, C is quite portable, as long as you keep several
< things in mind, like shorts are at least 16 bits, longs are at least 32
< bits, ints are at least 16 bits and can't be longer than a long, and don
< use functions not defined in the Standard C library (or stuff you've
< written).
Those things are or should be a given for any language. The problem in
all cases is when you talk to hardware, soon as you do that portability
is likely broken. This has always been true and until hardware is reduced
to one uniform platform (gag!). That is unlikely.
The C Standard guarentees a minimum size for various types; they can be
larger. Also, if you're hitting the hardware then of course the code is not
going to be portable (or portable to only those systems that support that
piece of hardware). Since that's the case, then what is typically done (or
rather, should be 8-) is to use system/compile specific extensions, but
isolate them.
For instance, I would specify an API to read/write at a generic level
(block_read(), block_write()) and create datatypes appropriate to the device
(block_t is a block number), and have code call this layer. This layer
would be the only thing to change, not the rest.
You might call this a device driver 8-)
I don't expect device drivers to be very portable. But well designed code
will minimize the non-portable stuff.
-spc (The Linux kernel proper is farily portable now ... )