On 2023-09-24, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Sun, 24 Sep 2023 00:39:15 +0300
> Anton Shepelev <anton.txt@gmail.moc> wrote:
>> Futhermore, some systems seem not to require alignment,
>> e.g.:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> void print_as( char const * data )
>> { for( int i = 0; i < 2; i += 1 )
>> { printf( "%i ", *((short*)(data+i*2)) ); }
>
> %hi would be more precise than %i .At the very least it saves the reader
> the trouble of trying to collect from the various points in the standard
> the information to decide whether just %i is also guaranteed to work.

People reviewing C code should know the utter basics, like that short
promotes to int. This is not an unreasonable expectation.

If the code creates an opportunity to get a refresher in a forgotten
matter in a fundamental language area, that's a good thing.

There is no reason to use a the h modifier with the signed conversion
specifiers d and i, if the argument is (before promotion) of type
short. In that situation it obviously does nothing.

All that the h does is insert an downcast. %hi is like %i except
that internally it convert the value to short, which can be imagined to
occur by a (short) cast.

That either does nothing (the value is in range of short due to having
been promoted out of short) or else produces an implementation-defined
result. Why bring that into the picture? That could become a problem
if the code is changed, and someone forgets to remove the h.

h only makes sense if you're passing a signed argument and want it
printed as unsigned. Say we have 16 bit short and 32 bit int.
Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
will obtain the desired 65535.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-24, Spiros Bousbouras <spibou@gmail.com> wrote:
>> { data[i] = (char)i%2; }
>
> (char)i will be promoted to something else (most likely int) before the
> % operation takes place so the cast is pointless. Even if you had written
> (char)(i%2) , given the values involved I don't see the point.

It has exactly the same point as your suggestion to use %hi instead of %i.

It feels more precise, by following an imaginary type system in which
imprecise features like promotions don't exist.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 9/24/23 07:48, Spiros Bousbouras wrote:
> On Sun, 24 Sep 2023 00:39:15 +0300
> Anton Shepelev <anton.txt@gmail.moc> wrote:
>> Futhermore, some systems seem not to require alignment,
>> e.g.:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> void print_as( char const * data )
>> { for( int i = 0; i < 2; i += 1 )
>> { printf( "%i ", *((short*)(data+i*2)) ); }
>
> %hi would be more precise than %i .At the very least it saves the reader
> the trouble of trying to collect from the various points in the standard
> the information to decide whether just %i is also guaranteed to work.

Just in case you wanted to know, here's the relevant sections:
"i The int argument ..." (7.19.6.1p8), which tells you that the argument
that corresponds to %i must be an int.

"If an int can represent all values of the original type, the value is
converted to an int; otherwise, it is converted to an unsigned int."
(6.3.1.1p2). Since all values representable as a short are also
representable as an int, short is always promoted to an int.

As a result, for printf(), "%hi" means the same thing as "%i"; it was
added solely for the purpose of allowing the same format string to be
used with both the printf family and the scanf family of functions.

>> printf("\n");
>> }
>>
>> int main()
>> { char* const data = malloc(5);
>> for( int i = 0; i < 5; i += 1 )
>> { data[i] = (char)i%2; }
>
> (char)i will be promoted to something else (most likely int) before the

Correct. It will normally be an int, unless CHAR_MAX > INT_MAX, in which
case char will promote to to unsigned int. That is possible only if char
is unsigned, and CHAR_BIT >= 16 (which does happen, but it's pretty
uncommon).

> % operation takes place so the cast is pointless. Even if you had written
> (char)(i%2) , given the values involved I don't see the point.

And, after being promoted to int or unsigned int, it will be converted
back to char.

On 2023-09-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> As a result, for printf(), "%hi" means the same thing as "%i"; it was
> added solely for the purpose of allowing the same format string to be
> used with both the printf family and the scanf family of functions.

It isn't the same. The h means that, internally, printf converts the
int argument value to short.

Thus, we cannot expect the correct decimal representation of INT_MAX
using printf("%hi\n", INT_MAX).

When used with d or i, h means "show me the implementation-defined
value when we truncate the argument to short".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 9/24/23 13:10, Kaz Kylheku wrote:
> On 2023-09-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> As a result, for printf(), "%hi" means the same thing as "%i"; it was
>> added solely for the purpose of allowing the same format string to be
>> used with both the printf family and the scanf family of functions.
>
> It isn't the same. The h means that, internally, printf converts the
> int argument value to short.

I meant that it is the same when passing a short argument. Sorry for not
being sufficiently specific.

Anton Shepelev <anton.txt@gmail.moc> writes:

> Tim Rentsch:
>
>> One further thought...
>>
>> As of C11, there is a type max_align_t, defined in
>> <stddef.h>, whose alignment is the maximum alignment
>> supported by the implementation. The grain size for
>> allocation should be a multiple of
>>
>> _Alignof (max_align_t)
>>
>> so this alignment can be supported. Also, the amount of
>> space you use for your "pre-array" metadata should be
>> chosen to be a multiple of _Alignof (max_align_t),
>> otherwise the array alignments might be off in some cases.
>
> [...] Yes, I have discussed this issue here before, and
> implemented a (I think Ben's) suggestion to calculate the
> negative offset as the size of the metadata structure
> rounded up to a power of two, which should ensure correct
> alignment in most cases.

Sometimes this technique will use too much space, and sometimes
too little. It's better to use a method that always works, if
one is available.

> Futhermore, some systems seem not to require alignment,
> [example removed]

It can happen that an implmentation doesn't need alignment on
some types but does need it on others. Moreover you want the
code that you write to be portable, so it's necessary to assume
that alignment requirements are in force.

In your particular case, a nice way to do it is as part of the
type definition for the array prefix metadata (I've forgotten
what you called it; here it is Header, and for expository reasons
I chose longer names for the structure members):

#include <stddef.h>

#define ALIGN_MAX _Alignas (max_align_t)

typedef struct {
size_t first_unused;
size_t total_available;
size_t element_size;
ALIGN_MAX char data[];
} Header;

Given this definition for the prefix metadata, there are simple
definitions for META() and DATA(), as follows:

Header *
META( void *elements ){
char *data = elements;
return data ? (Header*) (data - offsetof( Header, data )) : NULL;
}

void *
DATA( Header *h ){
return h ? h->data : NULL;
}

This approach provides just what you need, if C11 is available.

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> #include <stddef.h>
>
> #define ALIGN_MAX _Alignas (max_align_t)
>
> typedef struct {
> size_t first_unused;
> size_t total_available;
> size_t element_size;
> ALIGN_MAX char data[];
> } Header;
>
> Given this definition for the prefix metadata, there are simple
> definitions for META() and DATA(), as follows:
>
> Header *
> META( void *elements ){
> char *data = elements;
> return data ? (Header*) (data - offsetof( Header, data )) : NULL;
> }
>
> void *
> DATA( Header *h ){
> return h ? h->data : NULL;
> }

How about:

typedef ALIGN_MAX struct {
size_t first_unused;
size_t total_available;
size_t element_size;
} Header;

Header *
META(void *elements) {
return elements ? (Header *) elements - 1 : NULL;
}

void *
DATA(Header *h) {
return h ? h + 1 : NULL;
}

Can't we have ALIGN_MAX on the struct type, like with
__attribute__((aligned))?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> People reviewing C code should know the utter basics, like that short
> promotes to int. This is not an unreasonable expectation.

Amusing, in light of what follows.

> [...]
>
> h only makes sense if you're passing a signed argument and want it
> printed as unsigned. Say we have 16 bit short and 32 bit int.
> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
> will obtain the desired 65535.

Both of those have undefined behavior.

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> People reviewing C code should know the utter basics, like that short
>> promotes to int. This is not an unreasonable expectation.
>
> Amusing, in light of what follows.
>
>> [...]
>>
>> h only makes sense if you're passing a signed argument and want it
>> printed as unsigned. Say we have 16 bit short and 32 bit int.
>> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
>> will obtain the desired 65535.
>
> Both of those have undefined behavior.

Not both; the second one is okay.

(I should definitely not have asserted that the wrong example will print
a certain output, though it is an example of surprising output that
occurs in practice on common platforms.)

N3096 states, and C99 had a similar wording:

h Specifies that a following b, d, i, o, u, x, or X conversion
specifier applies to a short int or unsigned short int argument.

When the h is present, punning is allowed between signed and unsigned.

There is no wording which restricts by subset: that b, o, u, x and X
take an unsigned short, and only d and i take a short.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>
>>>>> Note by the way that sizeof (max_align_t) might not be the same
>>>>> as _Alignof (max_align_t).
>>>>
>>>> Indeed. I was curious about this, so I wrote a small test program that
>>>> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
>>>> on the implementation I'm using.
>>>>
>>>> I'm using gcc, which defines max_align_t as a struct containing a long
>>>> long, a long double, and optionally a __float128. It could have reduced
>>>> the size by making it a union rather than a struct, but there's rarely
>>>> (?) any reason to create objects of type max_align_t.
>>>
>>> Yes there is!
>>>
>>> union {
>>> foo_t x;
>>> bar_t y;
>>>
>>> // please give my own union maximum alignment --- without undue bloat
>>>
>>> max_align_t align;
>>> }
>>>
>>> A max_align_t that can only be used as _Alignof(max_align_t) is useless;
>>> it might as well be a #define ALIGN_MAX 16 constant in some header
>>> like <limits.h>.
>>
>> You need to think harder.
>
> I'm "thinking broader" instead, maybe?

No, you aren't. First you gave faulty reasoning for needing to
declare something that has type max_align_t. When that reasoning
was shown to be wrong you fell back to an imaginary world to say
something would be nice to have when the something provides no
greater expressive power than what is there already. It's great
to have new ideas, but not all new ideas are good ideas. There
is no need for what you propose, and thus adding it to C would
have negative value.

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>>> On 2023-09-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> [...]
>>>>>
>>>>>> Note by the way that sizeof (max_align_t) might not be the same
>>>>>> as _Alignof (max_align_t).
>>>>>
>>>>> Indeed. I was curious about this, so I wrote a small test program that
>>>>> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
>>>>> on the implementation I'm using.
>>>>>
>>>>> I'm using gcc, which defines max_align_t as a struct containing a long
>>>>> long, a long double, and optionally a __float128. It could have reduced
>>>>> the size by making it a union rather than a struct, but there's rarely
>>>>> (?) any reason to create objects of type max_align_t.
>>>>
>>>> Yes there is!
>>>>
>>>> union {
>>>> foo_t x;
>>>> bar_t y;
>>>>
>>>> // please give my own union maximum alignment --- without undue bloat
>>>>
>>>> max_align_t align;
>>>> }
>>>>
>>>> A max_align_t that can only be used as _Alignof(max_align_t) is useless;
>>>> it might as well be a #define ALIGN_MAX 16 constant in some header
>>>> like <limits.h>.
>>>
>>> You need to think harder.
>>
>> I'm "thinking broader" instead, maybe?
>
> No, you aren't. First you gave faulty reasoning for needing to
> declare something that has type max_align_t. When that reasoning
> was shown to be wrong you fell back to an imaginary world to say
> something would be nice to have when the something provides no
> greater expressive power than what is there already.

That sounds tautological; nothing provides greater expressive
power than that power which it has already.

> It's great
> to have new ideas, but not all new ideas are good ideas. There

I'm pretty sure that sticking a dummy member into a union so that it has
at least that member's alignment isn't a new idea, let alone my idea.

> is no need for what you propose, and thus adding it to C would
> have negative value.

Can you clarify what it is you think that I proposed?

I believe that it consisted entirely of the idea that max_align_t would
be improved if it were required to have a size that does not exceed its
alignment.

However, that literal idea has flaws, because what if there is no such
type? Say max alignment is four bytes, on a machine that doesn't have a
four byte type, only one or eight. max_align_t will have to be eight,
which will make the union larger than necessary. (This is why in the
code comment I wrote "without undue bloat": if bloat is due, it's due.)

The example given by Keith of how GCC defined max_align_t, however,
gratuitously makes the type larger by simply aggregating various types
via struct. The underlying platform does have types whose size is equal
to the alignment of that max_align_t.

If a reasonable requirement could be articulated to discourage that, it
would be good.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> #include <stddef.h>
>>
>> #define ALIGN_MAX _Alignas (max_align_t)
>>
>> typedef struct {
>> size_t first_unused;
>> size_t total_available;
>> size_t element_size;
>> ALIGN_MAX char data[];
>> } Header;
>>
>> Given this definition for the prefix metadata, there are simple
>> definitions for META() and DATA(), as follows:
>>
>> Header *
>> META( void *elements ){
>> char *data = elements;
>> return data ? (Header*) (data - offsetof( Header, data )) : NULL;
>> }
>>
>> void *
>> DATA( Header *h ){
>> return h ? h->data : NULL;
>> }
>
> How about:
>
> typedef ALIGN_MAX struct {
> size_t first_unused;
> size_t total_available;
> size_t element_size;
> } Header;
>
> Header *
> META(void *elements) {
> return elements ? (Header *) elements - 1 : NULL;
> }
>
> void *
> DATA(Header *h) {
> return h ? h + 1 : NULL;
> }
>
> Can't we have ALIGN_MAX on the struct type, like with
> __attribute__((aligned))?

Please find something better to do than post these
useless responses. I don't want to waste any more
time on them.

On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> h only makes sense if you're passing a signed argument and want it
> printed as unsigned. Say we have 16 bit short and 32 bit int.
> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
> will obtain the desired 65535.

There is something I had neglected to mention: the use of h for portability

If we have "%u" paired with an unsigned short, argument we have
a mismatch on a large number of platforms, where unsigned short promotes
to int. The %u specifier wants unsigned int.

%hu will take care of it somehow. It knows which way the unsigned
short argument has promoted, and recover the value.

The h modifier makes the conversion specifier compatible with either
a short or unsigned short argument. That means that on platforms where
they promote the same way, it expects an actual type of int.
On platforms where they don't it has to do something like, oh,
in the case of the unsigned specifier, assume that the argument
was converted from an unsigned short, and treat the bits accordingly.

If we want specifically %u for decimal output, and we know that
unsigned short promotes to int, we can get away with %d.

That's not correct if unsigned short isn't promoting to int, and
not applicable if we want %x/%X, %o or %b.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Can't we have ALIGN_MAX on the struct type, like with
>> __attribute__((aligned))?
>
> Please find something better to do than post these
> useless responses. I don't want to waste any more
^^^^^^^

Thanks for the hint; that informs me there is something wrong with it.

Indeed, _Alignas cannot be used that way, due to a constraint:

"The _Alignas specifier shall not be used in conjunction with either of
the storage class specifiers typedef or register." [N3096 6.7.5]

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> Can't we have ALIGN_MAX on the struct type, like with
>> __attribute__((aligned))?
>
> Please find something better to do than post these
> useless responses. I don't want to waste any more
> time on them.

Aha! I got it: let's take all the members of Header and wrap them into an
anonymous struct member. Then, put the _Alignas onto that member.

#include <stddef.h>

#define ALIGN_MAX _Alignas (max_align_t)

typedef struct {
ALIGN_MAX struct {
size_t first_unused;
size_t total_available;
size_t element_size;
};
} Header;

Header *
META(void *elements) {
return elements ? (Header *) elements - 1 : NULL;
}

void *
DATA(Header *h) {
return h ? h + 1 : NULL;
}

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> People reviewing C code should know the utter basics, like that short
>>> promotes to int. This is not an unreasonable expectation.
>>
>> Amusing, in light of what follows.
>>
>>> [...]
>>>
>>> h only makes sense if you're passing a signed argument and want it
>>> printed as unsigned. Say we have 16 bit short and 32 bit int.
>>> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
>>> will obtain the desired 65535.
>>
>> Both of those have undefined behavior.
>
> Not both; the second one is okay.

That is right. The wording in C11 is not completely clear on
the question; however, wording in the C23 draft clarifies the
issue, and establishes that the behavior in this particular
case is well-defined.

It's still a bad idea IMO to use %hu with an argument that
has (before promotion) a signed type, but that's a style
issue, and doesn't change the definedness of this case.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>
>> h only makes sense if you're passing a signed argument and want it
>> printed as unsigned. Say we have 16 bit short and 32 bit int.
>> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
>> will obtain the desired 65535.
>
> There is something I had neglected to mention: the use of h for portability
>
> If we have "%u" paired with an unsigned short, argument we have
> a mismatch on a large number of platforms, where unsigned short promotes
> to int. The %u specifier wants unsigned int.

A %u conversion specification is always okay for an unsigned
short argument, regardless of whether the argument promotes to
int or to unsigned int. Reading an integer-typed variadic
argument with the corresponding type of the other signedness
is allowed when the argument value is representable in both
types, which it always will be in this case even if unsigned
short promotes to int.

On 2023-09-26, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>
>>> h only makes sense if you're passing a signed argument and want it
>>> printed as unsigned. Say we have 16 bit short and 32 bit int.
>>> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
>>> will obtain the desired 65535.
>>
>> There is something I had neglected to mention: the use of h for portability
>>
>> If we have "%u" paired with an unsigned short, argument we have
>> a mismatch on a large number of platforms, where unsigned short promotes
>> to int. The %u specifier wants unsigned int.
>
> A %u conversion specification is always okay for an unsigned
> short argument, regardless of whether the argument promotes to
> int or to unsigned int.

> Reading an integer-typed variadic
> argument with the corresponding type of the other signedness
> is allowed when the argument value is representable in both
> types, which it always will be in this case even if unsigned
> short promotes to int.

OK, I see how that is derived. printf is now described as if using
va_arg to extract the promoted type of the conversion specifier's type,
and then converting the promoted type to the the specifier's type (which
can hardly be done in any other way).

C99 didn't have this, only "If any argument is not the correct type for
the corresponding conversion specification, the behavior is undefined."

(Even though it already featured the signed/unsigned flexibility
measure in va_arg!)

If %u is implemented in C99 using va_arg, it will be well defined
for an unsigned short argument. For it not to be well-defined, it would
have to use some other mechanism than va_arg, which is more fragile.
But that makes next to no sense; this is a defect fix, really.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> h only makes sense if you're passing a signed argument and want it
>>> printed as unsigned. Say we have 16 bit short and 32 bit int.
>>> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
>>> will obtain the desired 65535.
>>
>> There is something I had neglected to mention: the use of h for portability
>>
>> If we have "%u" paired with an unsigned short, argument we have
>> a mismatch on a large number of platforms, where unsigned short promotes
>> to int. The %u specifier wants unsigned int.
>
> A %u conversion specification is always okay for an unsigned
> short argument, regardless of whether the argument promotes to
> int or to unsigned int. Reading an integer-typed variadic
> argument with the corresponding type of the other signedness
> is allowed when the argument value is representable in both
> types, which it always will be in this case even if unsigned
> short promotes to int.

Agreed, but unfortunately the standard doesn't quite say that in
normative text -- until C23, as I discovered while writing this.

In C17 and earlier, 7.21.6.1p9 (The fprintf function) says:
If any argument is not the correct type for the corresponding
conversion specification, the behavior is undefined.

(The word "the" implies that there is only one "correct type".)

6.2.5p9 (Types) says:
The range of nonnegative values of a signed integer type is a
subrange of the corresponding unsigned integer type, and the
representation of the same value in each type is the same.
with a footnote:
The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values
from functions, and members of unions.
but of course footnotes are non-normative.

I can imagine a (contrived) conforming implementation that passes
int arguments in one set of CPU registers and unsigned int arguments
in another set of CPU registers, so that `printf("%u\n", 42);`
would very probably *not* print "42". Such an implementation
would violate the intent of that footnote, but would not as far
as I can tell violate any normative requirement. (In real life,
I'm sure no such implementation exists.)

But C23 (N3096 draft) changes the description for fprintf:
fprintf shall behave as if it uses va_arg with a type argument
naming the type resulting from applying the default argument
promotions to the type corresponding to the conversion
specification and then converting the result of the va_arg
expansion to the type corresponding to the conversion
specification.

and the description of the va_arg() macro explicitly allows the type
of the first argument and the type given by the second argument
to be corresponding signed and unsigned types, if the value is
representable in both types. (This goes back to C99.)

Prior to C23, though the <stdarg.h> macros are the obvious way to
implement the *printf() functions, the standard didn't require it
to behave that way.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>
>>>> h only makes sense if you're passing a signed argument and want
>>>> it printed as unsigned. Say we have 16 bit short and 32 bit int.
>>>> Then "%u"/(short) -1 will print as 429496725, whereas
>>>> "%hu"/(short) -1 will obtain the desired 65535.
>>>
>>> There is something I had neglected to mention: the use of h for
>>> portability
>>>
>>> If we have "%u" paired with an unsigned short, argument we have a
>>> mismatch on a large number of platforms, where unsigned short
>>> promotes to int. The %u specifier wants unsigned int.
>>
>> A %u conversion specification is always okay for an unsigned
>> short argument, regardless of whether the argument promotes to
>> int or to unsigned int. Reading an integer-typed variadic
>> argument with the corresponding type of the other signedness
>> is allowed when the argument value is representable in both
>> types, which it always will be in this case even if unsigned
>> short promotes to int.
>
> Agreed, but unfortunately the standard doesn't quite say that in
> normative text -- until C23, as I discovered while writing this.
> [...]

My position is that this rule was intended since at least C99
(and perhaps earlier) but was not expressed at unambiguously as
one might like.

Also I believe there is support for this view if one consults
various historical documents done by the ISO C committee.

Also I think it is rather pointless to debate whether the C
standard does or does not "say that in normative text" when
the normative text that is there lends itself to different
interpretations. We all agree on what words are used; what
the words mean in this case is more a subjective reaction
than an objective fact. And is pretty much beside the point
since what was intended and what was understood is the same
for most of the people who are familiar with the C standard.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-26, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>
>>>> h only makes sense if you're passing a signed argument and want it
>>>> printed as unsigned. Say we have 16 bit short and 32 bit int.
>>>> Then "%u"/(short) -1 will print as 429496725, whereas "%hu"/(short) -1
>>>> will obtain the desired 65535.
>>>
>>> There is something I had neglected to mention: the use of h for
>>> portability
>>>
>>> If we have "%u" paired with an unsigned short, argument we have a
>>> mismatch on a large number of platforms, where unsigned short
>>> promotes to int. The %u specifier wants unsigned int.
>>
>> A %u conversion specification is always okay for an unsigned
>> short argument, regardless of whether the argument promotes to
>> int or to unsigned int.
>>
>> Reading an integer-typed variadic
>> argument with the corresponding type of the other signedness
>> is allowed when the argument value is representable in both
>> types, which it always will be in this case even if unsigned
>> short promotes to int.
>
> OK, I see how that is derived. printf is now described as if using
> va_arg to extract the promoted type of the conversion specifier's
> type, and then converting the promoted type to the the specifier's
> type (which can hardly be done in any other way).
>
> C99 didn't have this, only "If any argument is not the correct type
> for the corresponding conversion specification, the behavior is
> undefined."

Please see my response to the parallel post by Keith Thompson.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>>> h only makes sense if you're passing a signed argument and want
>>>>> it printed as unsigned. Say we have 16 bit short and 32 bit int.
>>>>> Then "%u"/(short) -1 will print as 429496725, whereas
>>>>> "%hu"/(short) -1 will obtain the desired 65535.
>>>>
>>>> There is something I had neglected to mention: the use of h for
>>>> portability
>>>>
>>>> If we have "%u" paired with an unsigned short, argument we have a
>>>> mismatch on a large number of platforms, where unsigned short
>>>> promotes to int. The %u specifier wants unsigned int.
>>>
>>> A %u conversion specification is always okay for an unsigned
>>> short argument, regardless of whether the argument promotes to
>>> int or to unsigned int. Reading an integer-typed variadic
>>> argument with the corresponding type of the other signedness
>>> is allowed when the argument value is representable in both
>>> types, which it always will be in this case even if unsigned
>>> short promotes to int.
>>
>> Agreed, but unfortunately the standard doesn't quite say that in
>> normative text -- until C23, as I discovered while writing this.
>> [...]
>
> My position is that this rule was intended since at least C99
> (and perhaps earlier) but was not expressed at unambiguously as
> one might like.

It was not expressed in normative text, ambiguously or otherwise.

> Also I believe there is support for this view if one consults
> various historical documents done by the ISO C committee.

You wouldn't have specific citations, would you?

In any case, the language is defined by the standard, not by
historical documents with wording that never made it into the
standard. No implementer or programmer should have to consult
"historical documents" to determine what the standard requires.

> Also I think it is rather pointless to debate whether the C
> standard does or does not "say that in normative text" when
> the normative text that is there lends itself to different
> interpretations. We all agree on what words are used; what
> the words mean in this case is more a subjective reaction
> than an objective fact. And is pretty much beside the point
> since what was intended and what was understood is the same
> for most of the people who are familiar with the C standard.

You consider it pointless. I don't. I find both the intent behind
the standard and what the standard says interesting. In this case,
they were two different things, and I consider that to be a flaw
in the standard. I'm glad the flaw is being corrected in C23.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Spiros Bousbouras <spibou@gmail.com> writes:
> On Sun, 24 Sep 2023 00:39:15 +0300
> Anton Shepelev <anton.txt@gmail.moc> wrote:
>> for( int i = 0; i < 5; i += 1 )
>> { data[i] = (char)i%2; }
>
> (char)i will be promoted to something else (most likely int) before the
> % operation takes place so the cast is pointless. Even if you had written
> (char)(i%2) , given the values involved I don't see the point.

Would you have made the same argument had the '2' been a '3' and the '5'
been an unknown value? The defensive coder in me sees almost all
constants as a possibly having alternative values.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On Sat, 30 Sep 2023 13:50:51 +0300
Phil Carmody <pc+usenet@asdf.org> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
> > On Sun, 24 Sep 2023 00:39:15 +0300
> > Anton Shepelev <anton.txt@gmail.moc> wrote:
> >> for( int i = 0; i < 5; i += 1 )
> >> { data[i] = (char)i%2; }
> >
> > (char)i will be promoted to something else (most likely int) before the
> > % operation takes place so the cast is pointless. Even if you had written
> > (char)(i%2) , given the values involved I don't see the point.
>
> Would you have made the same argument had the '2' been a '3' and the '5'
> been an unknown value?

The 2 being a 3 would have made no difference to my points. 5 being some
other value would depend on what restrictions we would have about the set of
possible values. One needs some restrictions to be able to programme at all ,
even knowing that the possible value is an integer is also a restriction.

> The defensive coder in me sees almost all
> constants as a possibly having alternative values.

Prudent coding is also not placing undue burden on one's mental faculties : if
no obvious generalisation suggests itself then don't try to invent one. For
a kind of extreme anti-generalisation attitude I offer the following from the
inventor of Forth :

I do not have a piece of software that will handle N pin chips, even where N
is between 40 and 84. I have three versions each is specialized. To add the
code necessary to change the number of output pads is certainly possible. But
I don't need to solve the general problem when I only have to solve these
specific cases.

Chuck Moore
http://www.ultratechnology.com/tape1-2.htm

--
vlaho.ninja/prog

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>
>>>>> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>>>
>>>>>> h only makes sense if you're passing a signed argument and want
>>>>>> it printed as unsigned. Say we have 16 bit short and 32 bit int.
>>>>>> Then "%u"/(short) -1 will print as 429496725, whereas
>>>>>> "%hu"/(short) -1 will obtain the desired 65535.
>>>>>
>>>>> There is something I had neglected to mention: the use of h for
>>>>> portability
>>>>>
>>>>> If we have "%u" paired with an unsigned short, argument we have a
>>>>> mismatch on a large number of platforms, where unsigned short
>>>>> promotes to int. The %u specifier wants unsigned int.
>>>>
>>>> A %u conversion specification is always okay for an unsigned
>>>> short argument, regardless of whether the argument promotes to
>>>> int or to unsigned int. Reading an integer-typed variadic
>>>> argument with the corresponding type of the other signedness
>>>> is allowed when the argument value is representable in both
>>>> types, which it always will be in this case even if unsigned
>>>> short promotes to int.
>>>
>>> Agreed, but unfortunately the standard doesn't quite say that in
>>> normative text -- until C23, as I discovered while writing this.
>>> [...]
>>
>> My position is that this rule was intended since at least C99
>> (and perhaps earlier) but was not expressed at unambiguously as
>> one might like.
>
> It was not expressed in normative text, ambiguously or otherwise.
>
>> Also I believe there is support for this view if one consults
>> various historical documents done by the ISO C committee.
>
> You wouldn't have specific citations, would you?
>
> In any case, the language is defined by the standard, not by
> historical documents with wording that never made it into the
> standard. No implementer or programmer should have to consult
> "historical documents" to determine what the standard requires.
>
>> Also I think it is rather pointless to debate whether the C
>> standard does or does not "say that in normative text" when
>> the normative text that is there lends itself to different
>> interpretations. We all agree on what words are used; what
>> the words mean in this case is more a subjective reaction
>> than an objective fact. And is pretty much beside the point
>> since what was intended and what was understood is the same
>> for most of the people who are familiar with the C standard.
>
> You consider it pointless. I don't. I find both the intent behind
> the standard and what the standard says interesting. In this case,
> they were two different things, and I consider that to be a flaw
> in the standard. I'm glad the flaw is being corrected in C23.

I repeat my previous statements.