Re: do { quit; } else { }

On 4/15/25 03:40, Janis Papanagnou wrote:

On 14.04.2025 15:00, James Kuyper wrote:

On 4/14/25 00:43, Janis Papanagnou wrote:
...

Honestly, this is an old, known argument that I could never fully
understand. 'char' for characters, 'int' as a register sized entity,
'short' and 'long' as, say, additions. So far so good. "For a wide
variety of platforms" you cannot just use 'int' and hope that works
on 8, 16, or 32 bit processors the same way. Switching to 'long' or
'short' also doesn't provide any portability property since you've
no guarantee whether the necessary ranges can be represented with
them.

>
Huh? There's guarantees for every one of those types.

 
Has that changed?

No, that has not changed since C was first standardized, except by the
addition of _Bool and long long to the list. There are maximum permitted
values for the *_MIN macros #defined in <limits.h>, and minimum
permitted values for the *_MAX macros:

#define BOOL_MAX 1
#define CHAR_MAX UCHAR_MAX or SCHAR_MAX
#define CHAR_MIN 0 or SCHAR_MIN
#define UCHAR_MAX 255
#define USHRT_MAX 65535
#define SCHAR_MAX +127
#define SCHAR_MIN -128
#define SHRT_MAX +32767
#define SHRT_MIN -32768
#define INT_MAX +32767
#define INT_MIN -32768
#define UINT_MAX 65535
#define LONG_MAX +2147483647
#define LONG_MIN -2147483648
#define LLONG_MAX +9223372036854775807
#define LLONG_MIN -9223372036854775808
#define ULONG_MAX 4294967295
#define ULLONG_MAX 18446744073709551615

... - I recall that there were only "compare to"
relations defined, like               |short| <= |int| <= |long|
 
and there where systems where it was  |short| == |int| == |long|
and other systems with                |short| <  |int| == |long|
or    |short| < |int| < |long|   or   |short| == |int| <  |long|

"For any two integer types with the same signedness and different
integer conversion rank (see 6.3.1.1), the range of values of the type
with smaller integer conversion rank is a subrange of the values of the
other type." (6.2.5p10)
"The range of nonnegative values of a signed integer type is a subrange
of the corresponding unsigned integer type, ..." (6.2.5p11).

Note, however, that this does not constrain the physical sizes of the
types. A fully conforming implementation of C could have sizeof(short) >
sizeof(long long), so long as a short int has a sufficiently large
number of padding bits. You'd have a hard time convincing people that
this was a good idea, but it wouldn't prevent such an implementation
from conforming to the standard.

The guarantees associated with the older types make
them roughly equivalent to the following size-named types:
>
[un]signed char     [u]int_least8_t
[unsigned]short     [u]int_least16_t
[unsigned]int       [u]int_fast16_t
[unsigned]long      [u]int_least32_t
[unsigned]long long [u]int_least64_t

 
And that is where I have a different experience. - AFAICT, these
size equivalences were not a given.

They are implied by the limits I've listed above.

Even before the size-named types came out, I always programmed with
those types as if they were the corresponding size-named types listed
above. Those types weren't ideal - too few of them can be described as
corresponding to one of the fast size-named types. However, they were
portable if used with due consideration of what guarantees went with
each type.

 
Was your programming focused to systems where the sizes were (by
accident) equal?

For something like 30 years of my career, I worked under rules that
emphasized portability. If it was permitted for a conforming
implementation of C to have two types to have the same size, I was not
permitted to write code that assumed that they were different sizes. It
it was permitted for them to be different sizes, I was not permitted to
write code that assumed they were the same size. And of course, any
assumptions about the actual sizes of the types were strictly forbidden.