initializing an int variable with all F's

[CBFalconer]

Don't feel too bad... I almost posted the same reply before I
caught that it's only valid for signed types.

I have been inconsolable for days now. Just hiding in a corner and
beating myself with a cat-o-nine-tails. The indescribable agony I
am suffering!

 

[pemo]

The reason for using -1 instead of UINT_MAX is to allow for the case
when you, or a later maintainer, needs to change the unsigned int to
unsigned long, or unsigned long long. They must remember to hunt down
and change each and every place where a value is assigned or
initialized with UINT_MAX and change it to ULONG_MAX or ULLONG_MAX.
Miss one, and ka-boom!

Even if unsigned int is always large enough on the current platform,
this could happen if the program is ported to a platform where
UINT_MAX is less, requiring a change to ULONG_MAX.

The other reason is that you sometimes need to initialize opaque
unsigned types, that is those that don't directly have a _MAX in
<limits.h> (pre-C99), without looking up the type definition for the
type.

What do you replace:

size_t s = -1;

Could be UINT_MAX, ULONG_MAX, ULLONG_MAX, etc., on different
platforms.

Interesting point - thanks.

But, aren't you also implying that one shouldn't use manifest
constants like UINT_MAX etc?

 

[David Thompson]

Yes. DEC made several machines (such as the TOPS series) with 18 bit
int. The Honeywell L6 series used a 36 bit word; I do not recall
at the moment if it was an 18 or 36 bit int on the compilers.

Nits: DEC made PDP-6 and PDP-10 _machines_ with a 36-bit word and ALU,
and extensive 18-bit (halfword) _move_ operations but not arithmetic;
but addresses were (also) 18-bits so you could use address arithmetic
for some limited things -- as on many other architectures.
They also had hardware support for byte operations of any size from 1
to 36-bits, and are usually trotted out (along with GE/HIS and maybe
CDC) as one of the real (and once important) cases of non-8-bit (and
non-power-of-two-bit) bytes.

The TOPS-10 and TOPS-20 _operating systems_ ran on PDP-10 machines,
labelled as DECsystem 10 and DECsystem 20, but so did several other
(in-house/third-party) operating systems.

"PDP" (Programmed Data Processor) was the name for all of
classic-DEC's product line, until VAX. According to legend, the name
was orginally a way for customers to evade corporate/bureaucratic
restrictions on buying and operating things called "computers". The
other PDP-n machines were architecturally dissimilar, although PDP-7
and -9 (and I am told -4) did have 18-bit word.

I don't think there was ever a PDP-10 C compiler from DEC; in those
days they were strongly (even zealously) pushing BLISS instead for the
niche where C competed and eventually won. (By the later days of
PDP-11, and early VAX, DEC had con-C-ded. <G>) There may well have
been a DECUS (customer-contributed) one.

You could make reasonable arguments for SI18L36 or S18IL36. Or even a
compiler option to choose between them. You need P36 (well, actually
28 and probably 33) for char and void pointers; in theory you could
use 18 or maybe 19 for everything bigger, but it would be far too much
hassle to make use of the "saved" space, as well as breaking (code
using) the widespread though unjustified assumption that all C (data)
pointers are (approximately) the same, so I doubt anyone would bother.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Jean-Marc Bourguet]

I don't think there was ever a PDP-10 C compiler from DEC; in those
days they were strongly (even zealously) pushing BLISS instead for the
niche where C competed and eventually won. (By the later days of
PDP-11, and early VAX, DEC had con-C-ded. <G>) There may well have
been a DECUS (customer-contributed) one.

There has been a port of gcc done in the 2000 (http://pdp10.nocrew.org/),
and kcc (available at the same place) was older and I think mostly standard
conformant, at least when invoked with the correct options.

Yours,