2 Jul
2012
2 Jul
'12
11:08 p.m.
On 07/03/2012 12:15 AM, Mouse wrote:
Yup, that is one of those "sometimes". Or, at least, it can be; I've
seen "it'll never run on anything else" code ported to the next
hardware rev with great pain often enough that I'd be hesitant to write
that way myself, but sometimes such porting is unlikely enough that
paying the cost for it if-and-when is preferable to paying the
immediate costs of preparing for it now. And you are the one in a
position to estimate those things in this case, not me.
I'm sorta hesitant as well, but the architectures on which the sizes
of int and short aren't 32 and 16 bits are few and far between. If I'm
specifically building binaries for 64-bit machines on which they AREN'T
those sizes (which I have NEVER done, despite half the machines I work
on being 64-bit), then I take other measures.
This is an excellent point.
I am also usually guilty of automatically disliking change for
change's sake, which is what I perceive these "new" typedef abortions to
be. I learned C from the first edition of the K&R book, when the 2nd
edition of the K&R book was new. I like function prototypes, but aside
Or, of course, you could just not even pretend to
write portably.
Sometimes that's a right answer; [...]
I'm writing device drivers and comm
protocols for industrial control
systems. These boards will be made by the hundreds of thousands and
will never run any other processor. Do not make
the mistake of assuming that I don't know this language,
and don't make the mistake of assuming that anyone who doesn't use
this "uint32_t" noise is automatically writing inherently
non-portable code.
No, I don't make either of those assumptions. Nor am I writing
specifically to you in most of the arguments I make in this thread.
Portability is a matter of degree, not an absolute all-or-nothing
thing; neither is it a thing that can be conjured up by mechanical
application of any rules (like "use uint*_t") or wrecked by ignoring
them. It requires awareness of what the language does and doesn't
promise and thought about how that interacts with the assumptions your
code is making.
Not that I think _you_ need to be told any of this. But others reading
this thread, whether now or in the archives...well, some of them
probably don't either. But some of them likely do. from that, I write bog-standard (really friggin'
FAST) plain old C. I
find it to be extremely portable in all but the most unusual
of
situations, and for 99% of those, ntohl() and friends have solved my
problems.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA