2 Jul
2012
2 Jul
'12
4:23 p.m.
On Jul 2, 2012, at 6:53 PM, Sean Conner wrote:
And elsewhere. I can't count the number of places crypto code broke
on my first-gen Opteron system under Linux because the folks who
wrote the standard MD5 code assumed that "unsigned long" was always
32 bits. They didn't even have a halfway decent excuse, since alpha
and sparc64 had been around quite a while.
When the number of bits matters, uint32_t and friends are important.
When the size doesn't matter (e.g. if I really want the largest int
reasonably possible), I'll use "unsigned long" and friends. I find
that that is seldom the case, usually because I've at least assumed
a minimum or maximum out of range of some reasonable variation of
"int" or "long".
A corollary: uint32_t and friends are bad ideas for adding pointer
offsets, and I've seen stupid code using that, too (which breaks
really badly on some 64-bit code). That's why we have ptrdiff_t.
stdint.h is your friend, and anyone not implementing it (*cough*
MSVC *cough*) is not.
- Dave
It was thus said that the Great Tony Duell once
stated:
I'm not sure I follow you here. In C, you can indeed do a
sizeof(unsigned short)
and get back the size (in characters) of a short int (with the size in bits
of a character defined by CHAR_BIT).
But it's not defined in a standard, which is a problem. It could be 128
bits when it's compiled for all you know.
As a
digression, normally, assuming programming in C, you'd place a
"unsigned short" variable at the address of the SPI data register. (I'll
AFAIK sizeof(unsigned short) is not defined anywhere :-). > have none
of that uncivilized "uint32_t" bullshit that these kids have
> dreamed up...and, surprise, my code is VERY portable)
Well, that "uint32_t" crap is *very* useful for networking protocols or
binary file parsing.