[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Help with an algorithm
- From: Tim Hill <drtimhill@...>
- Date: Sat, 25 May 2013 14:24:26 -0700
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 <email@example.com> 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