Bart:

> Wouldn't it better to try minimising the range of types
> than advocating using even more?

Yes, but you'd still have to support two sets of types:
fixed-width ones, and ones with a width dependent on
hardware/implementation. You seem to ignore the latter
variety.

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

Bart <bc@freeuk.com> writes:

> On 13/09/2022 12:48, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 12/09/2022 21:37, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 12/09/2022 16:48, Ben Bacarisse wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> In the vast majority of cases, when I see intN_t I feel that
>>>>>> int_leastN_t or int_fastN_t would be better, because none of extra
>>>>>> guarantees of intN_t are needed. I usually just think "ah, this person
>>>>>> does not know about the alternatives".
>>>>>>
>>>>>>> I think to some extent it comes down to a subjective opinion of what
>>>>>>> we are willing to be wrong about and what we prefer to be correct
>>>>>>> about in how we code. There are always compromises.
>>>>>> What are some good examples if the use of the intN_t types?
>>>>>
>>>>> Of fixed width integer types in general?
>>>> No. Cases where intN_t is better than ether int_lastN_t or int_fastN_t,
>>>> except (and I've made this exception clear from the start) matching
>>>> externally imposed size requirements.
>>>
>>> My argument is not so much that "intN_t" types are really /better/
>>> than "int_leastN_t" or "int_fastN_t", but that the "least" and "fast"
>>> versions are not noticeably better. In most situations, /none/ of
>>> these types express /exactly/ what you want, with no more and no less.
>>> Generally, they all specify features that don't matter at the time.
>>> So the simpler and clearer choice then wins overall. (We may have
>>> different ideas about what "better" means.)
>> It's a relative term. When I see "int32_t" I imagine the programmer
>> considers that type to be better than the alternatives.
>
> The alternatives being...? I assume the ones you have in mind are int,
> int_least32_t and int_fast32_t.

Not int. int is not an alternative since it could have fewer than 32
bits.

> Use of int32_t at least guarantees you won't get 16 bits.

As do the alternatives we've been discussing here -- the types no one
seems to use.

> But if your requirements are known to fit into 32 bits, you also know
> that you won't be wastefully given 64 bits as might conceivably be the
> case with int_least32_t.

No. If int32_t exists, int_least32_t can't be 64 bits. These types are
for when you want to tell the reader "the smallest type >= N".

> If 32 bits might be too small, just use int64 and be done with it
> rather than faffing about with int_least32_t.

Faffing about is just spin. And if you need 64 bits, using
int_least32_t is not faffing about, it just wrong.

>> So I wonder why
>> the programmer thinks that limiting range is important.
>
>> Must this
>> object map to some hardware feature?
>
> We're talking about a lower level language, so yes it must.

I think you are misunderstanding. We should have a term for the use of
a fixed-width type intended to match something externally defined -- a
network header field, as OS structure, data in some fixed file format.
This use is 100% justified. It is, in my view, the main reason these
types exist. Let's call this is a "matching use".

That's what I meant here. When I see int32_t I ask myself what is this
matching use?

So we are talking /only/ about uses of the fixed-width types that are
not matching uses.

> If you are writing an application and you need a 'don't care' integer
> type, then that used to be 'int', but while I don't want to specify an
> exact type, I really want that to default to 64 bits not 32. With 64
> bits, values need to be 4 billion times bigger before they overflow.
>
> So, while C could conceivably have a 64-bit int, usually it's only 32
> bits, which I think is a problem.

Use int_fast64_t.

>>> But when we get to the "fast" types, the fun starts :
>>>
>>> void printtest3(uint_fast8_t x, uint_fast16_t y,
>>> uint_fast32_t z, uint_fast64_t w) {
>>> print_var(x);
>>> print_var(y);
>>> print_var(z);
>>> print_var(w);
>>> }
>>>
>>> For one thing, the person expecting to see a 16-bit "y" sees 16 hex
>>> digits, not 4.
>> Which is presumably what the author intended, no? I can't see what
>> point the code has other than to reveal the underlying width.
>
> The _Generic example was a very good one in showing the problems with
> C's zoo of integer types.

Except there seems to a very simple way to do what was wanted. It
looked a bit contrived to me.

> Wouldn't it better to try minimising the range of types than
> advocating using even more?

I am not advocating for more. Again that's just the spin you want to
put in my post.

--
Ben.

On 13/09/2022 16:50, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

>> Wouldn't it better to try minimising the range of types than
>> advocating using even more?
>
> I am not advocating for more. Again that's just the spin you want to
> put in my post.

But not for fewer either! C has far too many including all the 'least'
ones you seem to be in favour of.

These are the typical requirements:

(1) A "don't care" int type

(2) A byte type (most ideally unsigned) for things like representing
UTF8 strings

(3) A specific-width integer

For (1), C's 'int' at 32 bits is too narrow IMV for current 64-bit
machines. Overflow is a very real issue. And actually, it might even be
16 bits.

For (2), C offers 'unsigned char' or 'uint8_t'

For (3), C offers the int32_t family

This is a poor enough choice, made worse by the proliferation of types
that may or may not be compatible, and the difficulties of using
printf/scanf codes, or constructing literals, for those _t types.

But you want to make it worser by suggesting people use 'least' types.

Put this way, it's become a lot clearer to me why so many apps want to
clear up the mess (only partially as they can't fix printf or magically
make 726163 a 64-bit value) by superimposing their own types that they
can have a lot more confidence in and whose denotations are less severe
in their appearance.

Other languages mostly offer a better selection and more pleasing
typenames, except for (1), where either it only has width-specific types
(i32, Int64), or the 'Int' type is still 32 bits. I believe this is C's
influence still.

A few might offer 64 bits without needing to use 'Long', but I couldn't
tell you off-hand (other than mine of course).

On 13/09/2022 17:50, Ben Bacarisse wrote:
> I think you are misunderstanding. We should have a term for the use of
> a fixed-width type intended to match something externally defined -- a
> network header field, as OS structure, data in some fixed file format.
> This use is 100% justified. It is, in my view, the main reason these
> types exist. Let's call this is a "matching use".

In a different kind of language, I'd like to see a clear distinction
between different purposes of types. There could be a general "integer"
whose range was inferred by the compiler as necessary, useful for local
variables when you need counting, arithmetic, indexing, etc., but have
no interest in the implementation details.

Concrete integer types used for communicating with the outside - file
structures, foreign function interfaces, etc., - would be explicitly
fixed sizes and representations, but not support operations other than
loading and storing. These could also be used for data storage (in
particular, structs, arrays, and arrays of structs) where size is relevant.

And then you could make your own integer types that are explicit
subranges of "integer", along with properties such as wrapping behaviour.

Ada, I think, can do this kind of thing - as can C++, if you make
appropriate class templates (though you can't get rid of the built-in
types and behaviours).

But I don't think C is that kind of language, and I remain unconvinced
that heavy use of the "least" and "fast" types is anything more than
baby steps towards such abstractions. (I am, I think, a little more
open to their use than I was before this subthread started, however.)

David Brown <david.brown@hesbynett.no> writes:
[...]
> While thinking about newer C features, I have found another challenge
> with using multiple different sometimes incompatible aliases for
> integer types - _Generic. I don't know if you've used _Generic much,
> but it can sometimes be useful. Here is a small example :
>
> #include <stdint.h>
> #include <inttypes.h>
> #include <stdio.h>
>
> #define print_var(_x) \
> do { \
> printf("Var " # _x " = "); \
> printf( \
> _Generic(_x, \
> uint8_t : "0x%02" PRIx8, \
> uint16_t : "0x%04" PRIx16, \
> uint32_t : "0x%08" PRIx32, \
> uint64_t : "0x%016" PRIx64), \
> _x); \
> printf("\n"); \
> } while (0);

I'd use the predefined types unsigned char, unsigned short, et al rather
than the uintN_t types. For example, if uint32_t is unsigned int and
uint64_t is unsigned long long, then passing an unsigned long argument
is an error. Using the predefined types guarantees that you'll cover
all the integer types. You can use sizeof to determine the number of
digits.

Except that it all breaks down if some of the types in <stdint.h> are
defined as extended integer types. There's no good way for a _Generic
expression to cover all the integer types if the implementation supports
extended integer types. (Then again, I'm not aware of any
implementations that do so.)

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2022-09-13, David Brown <david.brown@hesbynett.no> wrote:
> But I don't think C is that kind of language, and I remain unconvinced
> that heavy use of the "least" and "fast" types is anything more than
> baby steps towards such abstractions. (I am, I think, a little more
> open to their use than I was before this subthread started, however.)

The "least" business is a straightforward extension of how the ordinary
types are. For instance, long is at least 32 bits wide, short at least
16 and so on. Thus, as a portable C programmer, or a programmer of
portable C, you're used to this "at least" reasoning anyway.

There are situations when you need some minimum width, and this is not
related to conforming to any external storage. Say you need a type to
hold a field of 30 bits.

Before C99 inttypes, you might reach for the smallest standard type
that will yield at least that many bits, and that would be unsigned
long.

However, unsigned long might be excessively wide, leading to wasted
storage.

So, you might have a typedef for it, and some discipline for configuring
the typedef for different build targets. On this target, unsigned int,
on that one unsigned long.

The type uint_least32_t typedef solves the problem: the target
implementation provides the type with the desired characteristics.

It's only one character longer than "unsigned long", and gets rid
of a mess of typedefs wrapped in #ifdefs and whatnot.

When C99 was new, I would have avoided using it, but 23 years having
passed, it's okay to use in most programs that don't have to be
portable to ridiculously old installations.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 13/09/2022 21:29, Kaz Kylheku wrote:
> On 2022-09-13, David Brown <david.brown@hesbynett.no> wrote:
>> But I don't think C is that kind of language, and I remain unconvinced
>> that heavy use of the "least" and "fast" types is anything more than
>> baby steps towards such abstractions. (I am, I think, a little more
>> open to their use than I was before this subthread started, however.)
>
> The "least" business is a straightforward extension of how the ordinary
> types are. For instance, long is at least 32 bits wide, short at least
> 16 and so on. Thus, as a portable C programmer, or a programmer of
> portable C, you're used to this "at least" reasoning anyway.
>
> There are situations when you need some minimum width, and this is not
> related to conforming to any external storage. Say you need a type to
> hold a field of 30 bits.
>
> Before C99 inttypes, you might reach for the smallest standard type
> that will yield at least that many bits, and that would be unsigned
> long.
>
> However, unsigned long might be excessively wide, leading to wasted
> storage.
>
> So, you might have a typedef for it, and some discipline for configuring
> the typedef for different build targets. On this target, unsigned int,
> on that one unsigned long.
>
> The type uint_least32_t typedef solves the problem: the target
> implementation provides the type with the desired characteristics.

You said you need a field of 30 bits, so how would uint_least32_t be
better than uint_32t?

> It's only one character longer than "unsigned long", and gets rid
> of a mess of typedefs wrapped in #ifdefs and whatnot.
>
> When C99 was new, I would have avoided using it, but 23 years having
> passed, it's okay to use in most programs that don't have to be
> portable to ridiculously old installations.

On Fortran IV in the 1970s (at least on byte-addressed machines), you
got fixed-width integers with:

integer*4

The 4 is the number of bytes it occupied. An unsized 'integer' would be
some default, probably the machine word size. This is about the time of
the original C, and really wasn't that difficult a concept.

(I used the same idea from the 80s: int*4 or int:32 for byte/bit counts,
or byte*4 etc for unsigned. I've moved on from that syntax, but I was
also long aware of a need for such types in low level code.

C took until C99 to have such a thing, and, as typically implemented in
stdint.h, it looks a complete hack. Eg. defining precise types on top of
imprecise ones, or creating unpredictable aliases.)

Bart <bc@freeuk.com> writes:
[...]
> You said you need a field of 30 bits, so how would uint_least32_t be
> better than uint_32t?
[...]

It's guaranteed to exist.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 13/09/2022 22:37, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> You said you need a field of 30 bits, so how would uint_least32_t be
>> better than uint_32t?
> [...]
>
> It's guaranteed to exist.
>

You mean, in the same way that it is better to use trigraphs ??( and ??)
instead of [ and ], because they are guaranteed to be available?

You might then appreciate how doing that would adversely affect
readability in the 99.99% of cases where [ and ] would have been
perfectly fine.

I have no great love for C as people here will know, but why the desire
to drag the language down by keeping it bogged down in this stuff?

(I have enough problems with those basic intN_t types in managing to
write them without a typo - see above!)

Bart <bc@freeuk.com> writes:
>On 13/09/2022 22:37, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> You said you need a field of 30 bits, so how would uint_least32_t be
>>> better than uint_32t?
>> [...]
>>
>> It's guaranteed to exist.
>>
>
>You mean, in the same way that it is better to use trigraphs ??( and ??)
>instead of [ and ], because they are guaranteed to be available?

Maybe he was refering to your mis-spelling of uint32_t?

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> ManyBeers <markzuffi@yahoo.com> writes:
>>>>
>>>>> Hello I am teaching myself C and I need some help with a problem.
>>>>> After a search for dec/oct convert I found this code:
>>>>>
>>>>> [..code..]
>>>>
>>>> I would like to offer a different kind of answer to your
>>>> questions. First a suggestion: for this kind of problem I think
>>>> you will find it helpful to use unsigned types exclusively. In
>>>> the code below we will need (besides a plain 'unsigned' here and
>>>> there) two types, one for 8-bit values and one for 32-bit values
>
> :
>
>>>> typedef unsigned char UC;
>>>> typedef unsigned int UI;
>>>
>>> There already standard perfectly cromulent typedefs for both,
>>> uint8_t and uint32_t.
>>
>> For the posted response and example I think unsigned {char,int}
>> are better suited.
>
> You said, and I quote:
>
> "two types, one for 8-bit values and one for 32-bit values

Yes, and I also said "unsigned {char,int} are better suited"
for the posted response and example. The quoted phrase was
put in to provide non-restrictive information about the two
types being used, and not to give a specification for those
types, which were given elsewhere in the posting.

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>
>>>> ManyBeers <markzuffi@yahoo.com> writes:
>>>>
>>>>> int convertDecimalToOctal(int decimalNumber);
>>>>
>>>> The following program tries to convert the number given in main
>>>> to its octal representation, which is printed to standard output.
>>>>
>>>> I wrote it just to the point where it seems to work for this
>>>> special case, but I'm not convinced that it will print the
>>>> correct result in all cases or does not overflow any of its
>>>> buffers!
>>>>
>>>> #include <stdio.h>
>>>> #include <string.h>
>>>>
>>>> /* are there digits above 0 in the buffer? */
>>>> int digits_in( char buffer[] )
>>>> { size_t i = 0;
>>>> for( ; i < strlen( buffer )&& buffer[ i ]=='0'; ++i );
>>>> return buffer[ i ]> '0' && buffer[ i ]<= '9'; }
>>>>
>>>> /* write div to "result" and returns the remainder */
>>>> int divrem
>>>> ( char dividend[], char result[], int base_of_dividend, int divisor )
>>>> { { size_t i = 0;
>>>> for( ; i < strlen( dividend ); ++i )
>>>> result[ i ]= ' '; result[ i ]= 0; }
>>>> int r = 0; int j = 0; int k = 0;
>>>> for( size_t i = 0; i < strlen( dividend ); ++i )
>>>> { if( dividend[ i ]!= ' ' )
>>>> { r = r * base_of_dividend + dividend[ i ]- '0';
>>>> if( r >= divisor )
>>>> { int const q = r/divisor; r = r%8;
>>>> result[ j ]=( char )( q + '0' ); }
>>>> else
>>>> { result[ j ]='0'; }} ++j; }
>>>> return r; }
>>>>
>>>> /* convert number, which is given in the base_of_dividend into
>>>> base_of_result */
>>>> void convert
>>>> ( char number[], char buffer[],
>>>> int base_of_dividend,
>>>> int base_of_result /* must not be larger than base_of_dividend */ )
>>>> { if( digits_in( number ))
>>>> { int const digit =
>>>> divrem( number, buffer, base_of_dividend, base_of_result );
>>>> { convert( buffer, number, base_of_dividend, base_of_result );
>>>> putchar( '0' + digit ); }}}
>>>>
>>>> int main( void )
>>>> { /* source in dec */
>>>> char a[] = "897528309349537459261193475234783479487034102857389475930";
>>>> /* the buffer must at least have a's len */
>>>> char b[] = " ";
>>>> convert( a, b, 10, 8 );
>>>> putchar( '\n' ); }
>>>
>>> Somewhat more concisely:
>>>
>>> $ cat /tmp/octal.c
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> #include <string.h>
>>>
>>>
>>> int
>>> main(int argc, const char **argv, const char **envp)
>>> {
>>> char buf[64];
>>> char *bp = &buf[64];
>>> uint64_t value;
>>>
>>> if (argc > 1) value = strtoul(argv[1], NULL, 0);
>>> else value = 0x400;
>>>
>>> *--bp = '\0';
>>> while (value > 0) {
>>> *--bp = '0' + (value & 7ul);
>>> value /= 8;
>>> }
>>>
>>> printf("Octal = %s\n", bp);
>>> return 0;
>>> }
>>
>> This code concisely solves a very different problem. SR's code
>> is meant to address the problem of converting values that will
>> not fit in any of C's standard integer types. This code doesn't
>> even try to do that.
>
> So, replace 'uint64_t' with 'mpz_t'. The rest remains basically
> unchanged.

And that is a solution to yet a different problem. Stefan Ram is
showing how to accomplish the conversion without relying on any
special libraries. The code he gave has value for people who
want to understand the nature of (one way to accomplish) the
conversion. Your suggestion throws away that value.

Bart <bc@freeuk.com> writes:
> On 13/09/2022 22:37, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> You said you need a field of 30 bits, so how would uint_least32_t be
>>> better than uint_32t?
>> [...]
>> It's guaranteed to exist.
>
> You mean, in the same way that it is better to use trigraphs ??( and
> ??) instead of [ and ], because they are guaranteed to be available?
[...]

No, I mean that you asked a question and I answered it.

I understand that you don't like the names. If uint32_t were called
uint_exact32_t, would you agree that uint_least32_t might be better than
uint_exact32_t in that context?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>On 13/09/2022 22:37, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> You said you need a field of 30 bits, so how would uint_least32_t be
>>>> better than uint_32t?
>>> [...]
>>>
>>> It's guaranteed to exist.
>>>
>>
>>You mean, in the same way that it is better to use trigraphs ??( and ??)
>>instead of [ and ], because they are guaranteed to be available?
>
> Maybe he was refering to your mis-spelling of uint32_t?

No, I saw that and ignored it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:

> But I don't think C is that kind of language, and I remain unconvinced
> that heavy use of the "least" and "fast" types is anything more than
> baby steps towards such abstractions.

Is anyone suggesting heavy use of least and fast types? Is anyone
suggesting such use would be even a tiny step towards data abstraction?
I'm not.

> (I am, I think, a little more
> open to their use than I was before this subthread started, however.)

That's interesting.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 13/09/2022 16:50, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> Wouldn't it better to try minimising the range of types than
>>> advocating using even more?
>> I am not advocating for more. Again that's just the spin you want to
>> put in my post.
>
> But not for fewer either!

No, as that would break existing code.

> C has far too many including all the 'least'
> ones you seem to be in favour of.

I am saying they should be used in preference to intN_t types in certain
(specified) situations. You can't possibly not know my position by now,
surely? This is just more spin.

I rarely use them.

--
Ben.

On 2022-09-13, Bart <bc@freeuk.com> wrote:
> You said you need a field of 30 bits, so how would uint_least32_t be
> better than uint_32t?

There is the catch. Unless you have reasons to suspect that your program
will be ported to a system where there is no uint32_t, then there
is no reason to use uint_least32_t.

It's "better" in that situation when it's available and uint32_t isn't.

Which explains why you you will hardly ever see it being used.

On 2022-09-13, Bart <bc@freeuk.com> wrote:
> On 13/09/2022 22:37, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> You said you need a field of 30 bits, so how would uint_least32_t be
>>> better than uint_32t?
>> [...]
>>
>> It's guaranteed to exist.
>>
>
> You mean, in the same way that it is better to use trigraphs ??( and ??)
> instead of [ and ], because they are guaranteed to be available?

Even if you suspect that your program will have to be manipulated in
some environment where those characters are missing, that doesn't mean
you have to use trigraphs. A file can be converted to trigraphs
by machine.

> You might then appreciate how doing that would adversely affect
> readability in the 99.99% of cases where [ and ] would have been
> perfectly fine.

uint_least32_t need only appear in your code once:

typedef uint_least32_t foo_bits_t;

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 13/09/2022 22:29, Kaz Kylheku wrote:
> On 2022-09-13, David Brown <david.brown@hesbynett.no> wrote:
>> But I don't think C is that kind of language, and I remain unconvinced
>> that heavy use of the "least" and "fast" types is anything more than
>> baby steps towards such abstractions. (I am, I think, a little more
>> open to their use than I was before this subthread started, however.)
>
> The "least" business is a straightforward extension of how the ordinary
> types are. For instance, long is at least 32 bits wide, short at least
> 16 and so on. Thus, as a portable C programmer, or a programmer of
> portable C, you're used to this "at least" reasoning anyway.
>
> There are situations when you need some minimum width, and this is not
> related to conforming to any external storage. Say you need a type to
> hold a field of 30 bits.
>
> Before C99 inttypes, you might reach for the smallest standard type
> that will yield at least that many bits, and that would be unsigned
> long.
>
> However, unsigned long might be excessively wide, leading to wasted
> storage.
>
> So, you might have a typedef for it, and some discipline for configuring
> the typedef for different build targets. On this target, unsigned int,
> on that one unsigned long.

In my line of work, that is invariably what you would have (at least,
for the more experienced programmers). Often such types would come with
the toolchain, or perhaps with libraries that you use - if not, most
professional embedded developers would at least have a set of fixed-size
types in a common header that they always used. There might be one
header for 8-bit 8051, one for 16-bit msp430, one for 32-bit 68k, and so
on. Or there might be a single common header that makes use of
<limits.h> and conditional compilation to handle it all automatically.
The use of explicit fixed-size types has been standard since the first
microcontroller developer tried C instead of assembly, but no one ever
bothered making types equivalent to the "least" or "fast" types.
(Though of course "int", "short", and "long" were used.)

>
> The type uint_least32_t typedef solves the problem: the target
> implementation provides the type with the desired characteristics.
>

There is no problem to solve. "uint32_t" says you have 32 bits.
Changing to "uint_least32_t" says you would swap the additional
knowledge and clarity (which you may not need now, but may be of
interest to others later) for a the promise of portability to a Cray
supercomputer from the mid 1970's, and a pointless comment that you want
this 32-bit number to be held in the smallest possible space.

If your code needs portability to a DSP, then there are portability
advantages in "uint_least8_t" and "uint_least16_t". But they are still
almost certainly a bad idea as the results on a system with CHAR_BIT
greater than 8 will probably not be optimal anyway.

There is a lot more practical relevance of the "fast" types, but with
the exception of "uint_fast8_t" in code that must be portable to 8-bit
devices and bigger, you are usually clearer and better off using "int"
or "unsigned int".

> It's only one character longer than "unsigned long", and gets rid
> of a mess of typedefs wrapped in #ifdefs and whatnot.
>
> When C99 was new, I would have avoided using it, but 23 years having
> passed, it's okay to use in most programs that don't have to be
> portable to ridiculously old installations.
>

On 14/09/2022 07:55, Kaz Kylheku wrote:
> On 2022-09-13, Bart <bc@freeuk.com> wrote:

>> You might then appreciate how doing that would adversely affect
>> readability in the 99.99% of cases where [ and ] would have been
>> perfectly fine.
>
> uint_least32_t need only appear in your code once:
>
> typedef uint_least32_t foo_bits_t;
>

That is a good point.

A key issue for all these types is what the name says, and what emphasis
it gives - what does it say about the relative importance of various
aspects and features of the type?

"uint32_t" says "this is an unsigned 32-bit integer". It does not
emphasis speed, or small size, or precise size (unlike a
"uint_exact32_t"). It's a type for working with numbers that can be up
to 32-bit in size.

In the context of other parts of code, it can be obvious that the exact
size is important - but it is usually only important in terms of being a
size that is big enough for your needs, and fits the target well. That
might sound exactly like a description of "uint_fast32_t", but it is
not. When you write "uint_fast32_t", you are telling the reader "this
code, and this variable, is speed critical" whether it is true or not.
It is a bit like declaring the variable "register" - the compiler will
ignore the hint (unless you try to take the variable's address), but it
tells human readers that you think the variable is critical.

But when you use the type "foo_bits_t", you are telling the reader this
is a variable for storing "foo_bits". That is much more useful
information. And it might have been relevant, when defining
"foo_bits_t", to tell the reader that minimising space is a critical
feature of the storage of "foo_bits".

On 14/09/2022 04:09, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> But I don't think C is that kind of language, and I remain unconvinced
>> that heavy use of the "least" and "fast" types is anything more than
>> baby steps towards such abstractions.
>
> Is anyone suggesting heavy use of least and fast types?

No, the suggestions have been that in many cases it would have been
better to use least or fast types instead of fixed size types. I
appreciate the difference - it may have been even better (for some value
of "better") to use other standard C types such as "int", or to use
application-specific types.

The reality is that fixed size types /are/ heavily used, at least in
some types of programming (I am clearly biased by my own experience in a
particular field). If these were to be replaced, in most cases, by
least or fast types, then the result would necessarily be heavy use of
least and fast types in such code.

> Is anyone
> suggesting such use would be even a tiny step towards data abstraction?
> I'm not.
>

They /are/ a step more abstract than the fixed size types - their
definition is in terms of functional features and not implementation
features.

>> (I am, I think, a little more
>> open to their use than I was before this subthread started, however.)
>
> That's interesting.
>

Discussions like these make you think (well, they make /me/ think - I
can't really answer for anyone else!). And if we think, with an open
mind, then it should result in a better understanding of alternative
ideas and opinions. That does not mean changing stances, or agreeing
with other people's arguments. But it does mean that when you see a
"uint32_t" variable in code that is not dictated by external forces, you
might be less inclined to think it is "knee-jerk programming" and more
inclined to consider that it might have been chosen carefully and
intentionally instead of "uint_fast32_t" or "uint_least32_t". And when
I next write code with a "uint32_t" variable, I will be more inclined to
consider if "uint_fast32_t" or "uint_least32_t" better expresses my
intentions, or improves portability or efficiency, and if that outweighs
other considerations.

On 13/09/2022 20:48, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> While thinking about newer C features, I have found another challenge
>> with using multiple different sometimes incompatible aliases for
>> integer types - _Generic. I don't know if you've used _Generic much,
>> but it can sometimes be useful. Here is a small example :
>>
>> #include <stdint.h>
>> #include <inttypes.h>
>> #include <stdio.h>
>>
>> #define print_var(_x) \
>> do { \
>> printf("Var " # _x " = "); \
>> printf( \
>> _Generic(_x, \
>> uint8_t : "0x%02" PRIx8, \
>> uint16_t : "0x%04" PRIx16, \
>> uint32_t : "0x%08" PRIx32, \
>> uint64_t : "0x%016" PRIx64), \
>> _x); \
>> printf("\n"); \
>> } while (0);
>
> I'd use the predefined types unsigned char, unsigned short, et al rather
> than the uintN_t types. For example, if uint32_t is unsigned int and
> uint64_t is unsigned long long, then passing an unsigned long argument
> is an error. Using the predefined types guarantees that you'll cover
> all the integer types. You can use sizeof to determine the number of
> digits.

That is clearly also possible (as is Ben's alternative suggestion). The
point of my example was not to make a perfect, portable variable print
solution, but merely to illustrate a situation where a simple and neat
_Generic pattern breaks down if you include the fast and least types.

>
> Except that it all breaks down if some of the types in <stdint.h> are
> defined as extended integer types. There's no good way for a _Generic
> expression to cover all the integer types if the implementation supports
> extended integer types. (Then again, I'm not aware of any
> implementations that do so.)
>
I too don't know of any C implementations that actually have extended
integer types, but I know that on the AVR the <stdint.h> types are
defined as "int" and "unsigned int" with different sizes according to a
gcc extension. I have not looked at how that might affect _Generic.

On 14/09/2022 00:15, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 13/09/2022 22:37, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> You said you need a field of 30 bits, so how would uint_least32_t be
>>>> better than uint_32t?
>>> [...]
>>> It's guaranteed to exist.
>>
>> You mean, in the same way that it is better to use trigraphs ??( and
>> ??) instead of [ and ], because they are guaranteed to be available?
> [...]
>
> No, I mean that you asked a question and I answered it.
>
> I understand that you don't like the names. If uint32_t were called
> uint_exact32_t, would you agree that uint_least32_t might be better than
> uint_exact32_t in that context?
>

Few like the names, and there would be a revolt I think if a u32 type
had to be written as uint_exact32_t. A lot more would just create their
own typedefs than already do. (It has already been suggested for
int_least32_t.)

But wasn't the purpose of stdint.h to stop the practice of everyone
inventing their own typenames for i8-u64/u8-u64? Instead it's
encouraging people to do so!

For uint_least32_t it isn't just the unwieldy name, it's the rather odd
concept that it introduces that makes you think.

I understand that the main use of such a type (let's call it u32+ for
short), is for when C is used on machines that doesn't have a native u32
type, not even expressed as two u16 words.

Apart from DSPs (which still mainly have power-of-two word sizes, but
some may only offer 64 bits), I'm only aware of ancient mainframes where
they might be employed (eg. PDP10 with 36-bit words, which I've used,
and CDC6600 with 60-bits, which I haven't).

On those, u32+ may be implemented as 36 or 60 bits; u32 would, what,
generate an error? (PDP10 did however offer packed 6- and 7-bit
characters with special instructions; here uint_least8_t would not help;
it would make less effective use of memory, and couldn't represent 6-
and 7-bit text used elsewhere.)

OK, if there is likelyhood, or, more probably, you KNOW, that you will
be using such a target, then sure, use a special type u32+ or typedefed
version of the full form (I would just call it 'intm' as I have done
elsewhere).

But Ben, as I understood (he will doubtless accuse me of misrepresenting
his words), was suggesting using Least types as a matter of routine,
irrespective of target machine.

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/11/22 11:01 PM, Tim Rentsch wrote:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> [...] I worry that, except when matching externally defined
>>> structures, the use of the intN_t (and maybe even the uintN_t)
>>> types is almost always knee-jerk programming.
>>
>> Completely agree.
>
> I would just slightly disagree.
>
> Many programs are not designed to be "highly portable", and it may be
> a reasonable assumption that a given program will only be run on
> machines which is based on 8 bit bytes.

I am taking 8-bit bytes as being the crucial property in the
remarks below. There are obvious counterparts for other
properties, such as having a two's complement representation.

> Since [u]intN_t is the shortest way to specify a size that will likely
> migrate over modereate architecture variations for variable where you
> do want to specify the "size" of the variable, using them makes sense.

First off, I wouldn't say using int8_t or uint8_t is the shortest
way to ensure 8-bit bytes. The way such types are typically
used, there will be lots of 'int8_t's or 'uint8_t's scattered
through the source code, with a correspondingly large footprint
in the program source. It is shorter to write in just one header
file in the program

#include <limits.h>
#if CHAR_BIT != 8
# error oops.. this program relies on chars being 8 bits...
#endif

typedef unsigned char U8;
typedef signed char S8;

which also can be used in implementations that don't support
C99.

Second, ignoring the question of which technique is shortest,
using [u]int8_t is often not a good way. A problem with the
exact width types is that they are both an under-specification and
an over-specification: over-specification because they often
include properties that aren't important (such as having no trap
representations), and under-specification because they might not
have properties that are otherwise desirable (such as being
exempt from anti-alias rules, as the character types are).
Granted, such problems are not likely to occur, but there is no
good reason to take the risk when it can be easily avoided.

Third, using exact width types can have consequences for parts of
the code other than declarations. In effect using exact width
types in one part of a program pushes the program into a mode
where exact width types more or less have to be used everywhere,
even when they are needed in only a few places. Even if exact
width types are an acceptable choice, in most cases they are not
the best choice.

In summary, I think a better statement is that [u]intN_t is the
laziest way to achieve what may not be a good result, and often
is a suboptimal result. The sad thing is that better techniques
don't need a lot of overhead; there is a small upfront cost, but
once that initial cost has been paid the incremental cost is
basically zero.

> Perhaps instead of making the type least_intN_t/fast_intN_t/intN_t
> they were defined instead as intN_t/fast_intN_t/exact_intN_t, or
> least_intN_t/intN_t/exact_intN_t so the simple name was one of the
> promised to exist types that might be bigger if needed, the short name
> bias would have lead to better code, but that ship has sailed.

Something that hasn't come up (I think) in the discussion of
various type choices is the distinction between types and the
names of types. In the code that I posted, the types used are
unsigned char and unsigned int. To help the discussion I put in
some typedefs to give the names UC and UI to these types, but
that doesn't change what the underlying types are. One problem
with the types in <stdint.h> is we don't know whether these names
refer to existing (standard) types, or whether they refer to
non-standard extended types. Are they fish or fowl? We don't
know. That uncertainty can cause difficulties in code that uses
some <stdint.h> types. For the most part I usually avoid using
any <stdint.h> types, for this reason and also for the reasons
explained above.

Kaz Kylheku <480-992-1380@kylheku.com> writes:

> On 2022-09-13, Bart <bc@freeuk.com> wrote:
>> You said you need a field of 30 bits, so how would uint_least32_t be
>> better than uint_32t?
>
> There is the catch. Unless you have reasons to suspect that your program
> will be ported to a system where there is no uint32_t, then there
> is no reason to use uint_least32_t.
>
> It's "better" in that situation when it's available and uint32_t
> isn't.

This all started because I think (u)int_least32_t and (u)uint_fast32_t
often better describe what the programmer intends:

int_least32_t: "I need at least 32 bits but I'm worried about space"
int_fast_32_t: "I need at least 32 bits but I'll take wider if it's faster"
int32_t: "I need exactly 32 bits, probably to match something external"

With the u versions, the last one (uint32_t) gets a new use: "I need
exactly 32 bits, possibly because the algorithm needs mod 2^32
wrapping".

> Which explains why you you will hardly ever see it being used.

I think there are other explanations.

--
Ben.