Bytes, chars, ints, etc (gnu algol 68, C, ...)

[Jose E. Marchesi]

> Jose and everyone,
>
> On Thu, Jan 15, 2026, 12:57 Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>> >> Hello All,
>> >>
>> >> Please let me know if this mail list is not the proper place for this
>> >> kind of question.
>> >
>> > It is exactly the right place :)
>> >
>> >> Recent postings touch upon "bytes" (with respect to transput), and
>> >> "chars" have been mentioned (with respect to unicode).
>> >>
>> >> Algol 68 was developed creating its own vocabulary for various
>> datatypes.
>> >>
>> >> C has data types: "char", "int", etc.  Types sizes became more diverse
>> >> yielding "short",  "int", "long int", "long long int".  Their actual
>> >> sizes may vary from system to system.
>> >>
>> >> To clearly fix the sizes to a given name, some languages (for example
>> >> zig) have created types such as:  unsigned integer types, "u8", "u16",
>> >> "u32, "u64, and float types "f16", "f32", etc.  The naming discloses
>> >> concrete numerical properties of each.
>> >>
>> >> Finally, here is the question:
>> >>
>> >> Given GNU Algol 68 shall be a superset, when introducing new primitive
>> >> types must we restrict ourselves to the using the same/similar names
>> >> used by "C"?  (And along with the "wiggle-room" on bytes sizes?)
>> >>
>> >> Or, would we be open for newer types with byte-size clarity from name.
>> >> (Question motivated most recently  by the "byte, bits, etc for binary
>> >> IO" postings.  Perhaps "u8" would be nice for this.)
>> >
>> > I have been actually reflecting about the possibility of having
>> > size-named integral modes, as aliases to the corresponding `sizety int',
>> > and I am coming to the conclusion that it may be not that good idea
>> > after all.
>> >
>> > Thing is, in C you have types:
>> >
>> >     char
>> >     short
>> >     int
>> >     long int
>> >     long long int
>> >
>> >
>> > which, depending on the target, may be of different sizes.  Also the
>> > `char' may be signed or unsigned.
>> >
>> > For example, a typical 32-bit target:
>> >
>> >     char      8-bit (signed)
>> >     short     16-bit
>> >     int       32-bit
>> >     long      32-bit
>> >     long long 64-bit
>> >
>> > And a typical 64-bit target:
>> >
>> >     char      8-bit (signed)
>> >     short     16-bit
>> >     int       32-bit
>> >     long      64-bit
>> >     long long 64-bit
>> >
>> > Then C added types like int8_t, int16_t, int32_t and int64_t.  These are
>> > aliases (typedefs) to the corresponding "unsized" type.  So in the
>> > 32-bit target you have:
>> >
>> >     typedef char      int8_t;
>> >     typedef short     int16_t;
>> >     typedef int       int32_t;
>> >     typedef long long int int64_t;
>> >
>> > This works well, in C.
>> >
>> > While discussing transput we thought about the possiblity of using a
>> > similar strategy in GNU Algol 68.  The idea would be the same: lets
>> > introduce aliases (mode names) with explicit sizes.
>> >
>> > For a typical 64-bit target:
>> >
>> >
>> >     mode Int8  = short short int,
>> >          Int16 = short int,
>> >          Int32 = int,
>> >          Int64 = long int;
>> >
>> >
>> > For a typical 32-bit target:
>> >
>> >     mode Int8  = short short int,
>> >          Int16 = short int,
>> >          Int32 = int,
>> >          Int64 = long int;
>> >
>> > Note that, unlike in C, they are the same in both arches!
>> >
>> > This is because, unlike in C, you cannot have a `long int' with the same
>> > size than an `int'.  This is because the language rules say that if you
>> > keep adding `long's at some point the precision "saturates" and further
>> > additions don't have any further effect.  There is an enviroment enquiry
>> > that tells you exactly how many `long's can you add that are actually
>> > relevant.  Same consideration applies for shortsetys.
>> >
>> > This is documented in the report:
>> >
>> >   2.1.3.1 Plain values
>> >
>> >   [...]
>> >
>> >   b) An arithmetic value has a "size" i.e., an integer characterizing he
>> >      degree of discrimination with which it is kept in the computer.
>> >
>> >   c) The mode of an integer or of a real number of size n is,
>> >      respectively, some 'SIZETY integral' or 'SIETY real' here, if n is
>> >      positive (zero, negative), that 'SIZETY' is n times 'long' (is
>> >      empty, is -n times 'short').
>> >
>> >   d) The number of integers or of real numbers of a given size that can
>> >      be distinguished increases (decreases) with that size until a
>> >      certain size is reached, viz., the "number of extra lengths" (minus
>> >      the "number of extra shorts") of integers or of real numbers,
>> >      respectively, after which it is constant.
>> >
>> >
>> > What I am coming to realize is that the C aliases would be pretty
>> > useless for Algol 68.  This is because there are no implicit coercions
>> > from, say, `short int' to `int'.  Widening only happens from int to real
>> > of same sizety, and from real to complex of same sizety.  (Genie has an
>> > extension to allow the other kind of coercions, but I don't want to
>> > support it.)  This means that you would start writing something like the
>> > following, to initialize a counter to zero:
>> >
>> >
>> >      Int64 counter := _
>> >
>> >
>> > and then, what, should you write:
>> >
>> >      Int64 counter := long 0;
>> >
>> > or should you write:
>> >
>> >      Int64 counter := long long 0;
>> >
>> > You see the point: the programmer needs to know the size of all the
>> > supported `sizety int'.  If she doesn't, she will never be able to work
>> > with the "sized" integral aliases.  And if she does, then she doesn't
>> > need the sized integral aliases.
>> >
>> > HOWEVER...  this may be just fine.
>> >
>> > The reason why in C int64_t, etc, are so useful, is because given the
>> > size of `int' you cannot really determine the size of the other types:
>> > `long int' may be 32 bit, or 64.
>> >
>> >
>> > But if to the existing Algol 68 rules we add a new one, as an extension,
>> > saying that each increment (decrement) in size shall be doubling
>> > (halving) the underlying number of bits, then given the size of `int and
>> > the number of meaningful sizes, we can derive the size of any `SIZETY
>> > int'.
>> >
>> > In other words, if `int' is 32-bit, `long int' will always be 64-bit, if
>> > it is meaningful.  And `short int' and `short short int' will always be
>> > 16-bit and 8-bit if they are meaningful.
>> >
>> > This could not accommodate targets with "non-regular" register sizes
>> > such as 40 or 24 bits, but it _can_ accommodate true 16-bit targets, for
>> > example, where you could have the following meaningful sizeties:
>> >
>> >
>> >       short int -> 8-bit
>> >       int       -> 16-bit
>> >       long int  -> 32-bit
>> >
>> > And even true 8-bit targets:
>> >
>> >       int      -> 8-bit
>> >       long int -> 16-bit
>> >
>> > So at this point my thinking (at least for now 8-)) is:
>> >
>> > 1. Adding explicitly sized integral mode names like Int64 and friends is
>> >    not a good idea.
>> >
>> > 2. We should not fix Byte to be `short short int'.  It should be set by
>> >    the compiler to be an alias to whatever `SIZETY int' mode is 8-bit.
>> >
>> > 3. There must be always a `SIZETY int' mode with size 8-bit.
>> >
>> > Thoughts?
>>
>> Just wanted to add a practical note.
>>
>> In all targets currently shipped in GCC, to the best of my knowledge,
>> `int' is 32-bit.
>>
>> This means that in virtually every target used today,
>>
>>   `short short int' will be 8-bit.
>>   `short int'       will be 16-bit.
>>   `int'             will be 32-bit.
>>   `long int'        will be 64-bit.
>>   `long long int'   will be 128-bit (if supported by the arch).
>>
>> But, the proposed rule still allow supporting the language in
>> architectures where you would typically use other compilers (even if
>> there are some GCC ports available for these, off-tree) and where an
>> `int' would need to be, for example, 16-bit, or even 8-bit.
>>
>> So, for all practical purposes, `long int' will always be 64-bit.
>>
>> Pietro: and this means we would have to change lseek to use `long int'
>> and not `long long int'.
>>
>
> There are some other related things to consider.
>
> For example not every other Algol 68 is going to support UCS-4, or even
> Unicode. Someone might follow Java's path and char could be 16 bit.

I don't follow.  How is the absence of Int8, Int16, etc impacting that?

> And the wonder that is 80 bit extended precision floating point...

Ditto.

> Anyway... If we are to support writing 8 bit somethings from GNU Algol 68
> and continue to recognize that byte as defined in the RR is
>
> counterproductive (to say the least), we will want to be able to refer to
> something like
>
> []short short bits
>
> knowing that short short bits is 8 of those very same bits.
>
> And so probably we will become tired and grumpy writing short short bits
> all the time...
>
> As you say the compiler could supply this name somehow but then we should
> still come up with a name that we like, ¿no?
>
> By the way given that the RR separates arithmetic operations on int base
> modes from but twiddling operations on bits base modes, we really need two
> compiler supplied modes "equivalent to" short short bits and short short
> int with the ability to coerce one to the other and vice versa.
>
> Depending on what we are doing in a given module it may be worthwhile to
> define arithmetic operators on bits and bit twiddling operators on int by
> encapsulating the appropriate calls to BIN and ABS.


Yes the mode compiler-provided Byte we want to add technically has the
same problem than Int8, Int16, etc.

But considering that the _vast_ majority of targets, in GCC or
otherwise, have 32-bit int and 16-bit short int and 8-bit short short
int, a program that does:

    Byte b = short short 16rff;

ought to be pretty darn portable..

So I think this won't be a problem in practice and we can proceed with
defining Byte as `short short bits' unconditionally. Algol 68 programs
written for the Commodore 64 won't be very portable, but such is life..

> I feel that I'm going on too long here...

You can even go long long!