Re: Help with an algorithm

[Tim Hill <drtimhill@...>]

typo .. i meant "unsigned long long", which *is* typically 64-bits on any C99 compliant compiler. You are of course correct of the chaos in the meanings of the various integer widths, outside of those defined by stdint.h.

I didn't suggest that anyone "eyeball" anything, and don't feel that my comment deserved such an ad hominem reply.

On May 25, 2013, at 2:03 PM, petah <lua@laufenberg.ch> wrote:

>> On most platforms these days unsigned long is 64 bits (however, note the "most").
> 
> That's a very unhelpful comment even if it were true, but it isn't.
> 
> First, the sign hardly matters. Second, a C type's size is set in stone by a /compiler/, not a platform or CPU, as is struct alignment. Apple actually changed type sizes from one OSX version to the next. Whether by "most" you mean PCs and/or cellphones, then "most" define long as 32-bit (VisualC @ x64 or Clang/iOS @ x32). The C standards defines ranges, not fixed sizes. In retrospect is seems a bad idea but at the time there were all sorts of funky CPUs... we're lucky they were all binary. A long does currently occupy 8 bytes on *nix64, "mostly", but one can hardly use that probability as a basis for design.
> 
> If you want fixed type sizes include "stdint.h" and use uint32_t, say, but watch those truncation warnings.
> 
> Making assumptions about C type sizes or suggesting that eyeballing today's landscape is good enough to draw conclusions is year-2000 type shortsightedness and does a real disservice to portable code... or those who'll have to debug it down the road :)
> 
> -- p
>