🚀 go-pugleaf

On Sat, 30 Sep 1995, Lawrence Kirby wrote:

> Actually I believe that is one of its strengths that has facilitated its
> spread over many platforms and its widespread use.

Maybe. It has certainly made supporting different platforms easier, but 
it has also made porting applications more difficult (especially to 
MS-DOG -- then again, this toy OS has memory limitations too).

> 16 bit values are enough for a surprisingly large number of circunstances.
> If you want an integer that is at leas 32 bits wide C provides the long type
> which has precisely this definition. If you want a type that is as close
> to 32 bits as possible (but no less) and are afraid that longs will be
> too long you can trivially set up a suitable typedef using the preprocessor.

16-bit values are enough for many applications -- I'll agree with that. 
For 90% of indexing operations and the like, it is easily good enough. 
However, as soon as you start multiplying... 16-bit values really get in 
your way.

What I'm saying is that though the 16-bit integers have been adequate in 
the past, they will no longer be adequate in the future. Often there is 
no need for 64-bit values, but that's what you'll get if you use ints on 
64-bit machines -- this isn't so bad. But if you use ints, sometimes you 
might end up with 16-bit values.

I just think that the standard should be moved up: ints should be *at 
least* 32-bits (64 wouldn't be too bad either), and longs should be 64-bit.

> As stated C provides exactly that - it is called a long.

I just think that 32-bit values are the starting point for "reasonable". 
And what if you want extra-long values? There's always GNU's long long, I 
guess, but that's non-standard.

> As yet I have not seen a single valid use for an exact 32 bit integer (at
> least not in portable code). This idea seems to come up a lot but nobody
> seems to be able to suggest an application for it that can't be reasonably
> done in an 'at least 32 bit' type. The nearest seem to be dealing with
> external data formats but even these are subject to problems like byte
> ordering and there are non-trivial standards and libraries to do this sort
> of thing correctly.

I guess I've changed my mind on this (sort of). For the most part, 
libraries could be built to handle exact-sized values (as well as byte 
ordering). However, some sort of standardization would be nice 
(otherwise, you get a myriad of typedefs, most meaning exactly the same 
thing).

> I see this is cross-posted to comp.lang.ada which I understand has such
> facilities. So I guess ADA users would have useful input on this. Have
> you found exact-width types to be useful, such that using a minimum width
> type instead would have been a problem?

It seems that Ada has everything... along with massive specifications. 
One thing that should be preserved in C (or its descendants) is its basic 
simplicity, but there's a fine line between simplicity and capability.

- Trung