Re: VMS

On 6/28/25 3:52 AM, Richard Kettlewell wrote:

c186282 <c186282@nnada.net> writes:

On 6/27/25 1:40 PM, rbowman wrote:

On Fri, 27 Jun 2025 13:24:06 -0400, c186282 wrote:

Some of us are old enough to remember when CPUs were not always
4/8/16/32/64 ... plus even now they've added a lot of new types like
128-bit ints. Simply ASSUMING an int is 16 bits is 'usually safe'
but not necessarily 'best practice' and limits future (or past)
compatibility. 'C' lets you fly free ...  but that CAN be straight
into a window pane

Assuming an int is 16 bits is not a good idea. I wouldn't even assume
a short is 16 bits

 (Apart from c186282 who for some reason thinks it’s “usually safe”,
nobody here is making any such assumption about int.)

   Eh ? I've been saying no such thing - instead recommending
   using sizeof() kind of religiously. I remember processors
   with odd word sizes - and assume there may be more in
   the future for whatever reasons.

Voice of experience for sure. Things have been represented/handled
just SO many ways over the years. Using sizeof() is 'best practice'
even if you're Just Sure how wide an int or whatever may be. 24 bits
are still found in some DSPs and you MAY be asked someday to patch or
port one of the old 12/18/24/36/48 programs.

 The thread is not about the size of int, etc. It’s about the specific
case of sizeof(char) in C, and that is always 1.

   CHAR is ONE BYTE of however many bits, but beyond that ..........
   Use sizeof() ...
   One flaw of sizeof() is that it reports in BYTES ... so,
   for example, how many BITS is that ? I've done stuff with
   low-resource micro-controllers and you use bit-fields to
   really pack in the data. Dealing with that level of potential
   incompatibility is a little more difficult and 'limits.h'
   can be helpful. The really rude way would be to have a
   little roll-over test function ... keep counting up until
   the field rolls back to zero. You'd only need it once.