Re: #define BITS_PER(x) (8 * sizeof(x))

James Dow Allen wrote:
Keith Thompson <kst-u@xxxxxxx> might have writ, in news:lnmy956lqy.fsf@xxxxxxxxxxxxxxx:

James Dow Allen <jdallen2000@xxxxxxxxx> writes:
Summary.
I will continue to use something like
#define BITS_PER(x) (8*sizeof(x))
If I get paranoid I'll call a test routine early in
main(), something like
Sorry, I must have missed something. I'd definitely use CHAR_BIT, not
8, for two reasons. First, and perhaps *less* important, CHAR_BIT
isn't necessarily 8 on all systems (I say this may be less important
because I've never programmed for a system with CHAR_BIT != 8).
Second, it's clearer to use a symbolic name rather than a magic
number.

Why do you think 8 might be better than CHAR_BIT?

No one has, as yet in this thread, presented a specific system where
char_bit != 8,

Plenty have been presented in the past. It is actually quite common for certain types of processors, such as DSPs.

nor where integers have padding

That would be more unusual.

BUT an unchallenged inference from Twirlip's comments suggest that this (hypothetical?) machine has 9-bit chars and 32-bit integers.

People are allowed to present hypothetical machines to make a point. I assume that is 32 value bits with 4 padding bits.

*Then* 8*sizeof would
work but char_bit*sizeof *not* work.

That would be far more unusual that the situation where CHAR_BIT*sizeof worked but 8*sizeof was wrong.

Another reason to suspect this is the correct approach is that
GMP uses 8, not char_bit. GMP is a very thoroughly tested and
ported piece of code.

That does *not* mean it is maximally portable. For a start, it's main targets (according to its web page) are Unix like systems (and POSIX requires CHAR_BIT==8) with it also having been ported to Windows. So they do not claim it is portable to machines where CHAR_BIT!=8.

Finally, if ints DO have 36 bits but code assumes 32 bits, the
code (if coded with care) will still work, but the converse
obviously doesn't apply.

True.

The *real* solution is for the "standard header(s)" to contain
a BITS_PER_INT define and my question remains: Why don't they?
(Committee oversight is not an adequate answer; if the standard
needs to evolve, let it evolve.)

Put in a request for it to be added to the standard. You could start by asking on comp.std.c where people on the standards committee are more likely to see the question.
--
Flash Gordon
.

Relevant Pages

  • Re: #define BITS_PER(x) (8 * sizeof(x))
    ... (Committee oversight is not an adequate answer; if the standard ... needs to evolve, let it evolve.) ...
    (comp.lang.c)
  • Re: DAT playback issue- refresher course needed
    ... and the interfaces are nonstandard and do not actually ... They will usually work with most AES/EBU devices ... off of hours and hours of tapes (recorded on many different machines), ... standard digital I/O and a reliable transport. ...
    (rec.audio.pro)
  • Re: Accessing Apps through RWW
    ... It is Standard with 2 nics. ... When I setup the machines using the connect ... computer wizard I got a message stating that I am not authorized to view this ...
    (microsoft.public.windows.server.sbs)
  • Re: LSE64 in standard Forth
    ... complement machines for ages, so it's simply the same thing as with C: ... two's complement unless you are on a really exotic piece of hardware. ... But in Standard Forth it's not well defined, not because of the two's complement issue, but because of the size. ... Three of the four C implementations listed in K&R edition 1 are 8/16/32 bit machines. ...
    (comp.lang.forth)
  • Re: Reply to Wolf
    ... So how did it ever evolve? ... Machines do not have to be seen as models of anything. ... It has to with the system that does the learning. ... Actually I don't think random behaviors are the only movers ...
    (comp.ai.philosophy)