Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #161421 > unrolled thread

#include <stdint.h>

Back to article view | Back to comp.lang.c

Contents

  #include <stdint.h> SIMON <invalid@invalid.invalid> - 2021-06-13 23:08 +0100
    Re: #include <stdint.h> Bart <bc@freeuk.com> - 2021-06-13 23:27 +0100
      Re: #include <stdint.h> Bart <bc@freeuk.com> - 2021-06-13 23:57 +0100
        Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 09:03 +0200
          Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-14 01:23 -0700
            Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 12:31 +0200
          Re: #include <stdint.h> Bart <bc@freeuk.com> - 2021-06-14 11:54 +0100
    Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-13 18:34 -0400
    Re: #include <stdint.h> Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-13 23:34 +0100
    Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-13 17:48 -0700
      Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 09:09 +0200
        Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-14 01:24 -0700
          Re: #include <stdint.h> Philipp Klaus Krause <pkk@spth.de> - 2021-06-14 12:30 +0200
      Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-24 10:31 -0700
        Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 11:28 -0700
          Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 02:49 -0700
            Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-11 15:30 -0700
              Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-16 03:33 -0700
                Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-16 12:31 -0700
                  Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-30 07:07 -0700
                    Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-30 08:42 -0700
                      Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 03:55 -0700
                        Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 07:06 -0700
                        Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-06 11:47 -0400
          Re: #include <stdint.h> Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-10-06 09:35 -0700
            Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 10:06 -0700
            Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-06 17:40 -0400
              Re: #include <stdint.h> Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 22:14 +0000
                Re: #include <stdint.h> James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-06 20:06 -0400
                  Re: #include <stdint.h> Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 02:15 +0000
        Re: #include <stdint.h> Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-24 22:34 +0100
          Re: #include <stdint.h> Öö Tiib <ootiib@hot.ee> - 2021-06-24 15:01 -0700
            Re: #include <stdint.h> Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 15:26 -0700
          Re: #include <stdint.h> Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 02:14 -0700

Page 2 of 2 — ← Prev page 1 [2]

#162883

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> I think it's not so much misunderstanding as disagreement.
>>
>> You wrote:
>>
>>     Whether the C standard "actually says" that the va_arg rules apply
>>     to *printf functions is, I think, not an answerable question, and in
>>     any case not really a useful question for purposes of comp.lang.c.
>>
>> I simply disagree.  It is an answerable question, [...]
>
> The question I am considering does not have an objective answer.
> Did you not understand that?

I understood what you said.  I think you're wrong.  Did you not
understand that?

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#163013

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:
>
> [...]
>
>>> I think it's not so much misunderstanding as disagreement.
>>>
>>> You wrote:
>>>
>>>     Whether the C standard "actually says" that the va_arg rules apply
>>>     to *printf functions is, I think, not an answerable question, and in
>>>     any case not really a useful question for purposes of comp.lang.c.
>>>
>>> I simply disagree.  It is an answerable question, [...]
>>
>> The question I am considering does not have an objective answer.
>> Did you not understand that?
>
> I understood what you said.  I think you're wrong.  Did you not
> understand that?

I understood your statement.  But I don't know what proposition
it is that you think is wrong.  Please note what I said:  the
question I am considering does not have an objective answer.  Are
you assuming that the question I am considering is the same as
the question you are considering?  My statement is about the
question I am considering, not about the question you are
considering.  At this point it seems apparent that they are not
the same question.  Do you agree or disagree with that last
sentence?

[toc] | [prev] | [next] | [standalone]

#163020

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:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>>> I think it's not so much misunderstanding as disagreement.
>>>>
>>>> You wrote:
>>>>
>>>>     Whether the C standard "actually says" that the va_arg rules apply
>>>>     to *printf functions is, I think, not an answerable question, and in
>>>>     any case not really a useful question for purposes of comp.lang.c.
>>>>
>>>> I simply disagree.  It is an answerable question, [...]
>>>
>>> The question I am considering does not have an objective answer.
>>> Did you not understand that?
>>
>> I understood what you said.  I think you're wrong.  Did you not
>> understand that?
>
> I understood your statement.  But I don't know what proposition
> it is that you think is wrong.  Please note what I said:  the
> question I am considering does not have an objective answer.  Are
> you assuming that the question I am considering is the same as
> the question you are considering?  My statement is about the
> question I am considering, not about the question you are
> considering.  At this point it seems apparent that they are not
> the same question.  Do you agree or disagree with that last
> sentence?

You're resurrecting a discussion from several months ago.  I'm not
sufficiently interested to go back and refresh my memory of what
we were talking about.  History does not suggest that we would reach a
meaningful conclusion.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#163022

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:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>>> I think it's not so much misunderstanding as disagreement.
>>>>
>>>> You wrote:
>>>>
>>>>     Whether the C standard "actually says" that the va_arg rules apply
>>>>     to *printf functions is, I think, not an answerable question, and in
>>>>     any case not really a useful question for purposes of comp.lang.c.
>>>>
>>>> I simply disagree.  It is an answerable question, [...]
>>>
>>> The question I am considering does not have an objective answer.
>>> Did you not understand that?
>>
>> I understood what you said.  I think you're wrong.  Did you not
>> understand that?
>
> I understood your statement.  But I don't know what proposition
> it is that you think is wrong.

He was quite clear about that - your proposition that it is "not an
answerable question". He believes it is an answerable question - he said
so explicitly.

> ...  Please note what I said:  the
> question I am considering does not have an objective answer.

Precisely - that is the assertion he's clearly disagreeing with.


> ...  Are
> you assuming that the question I am considering is the same as
> the question you are considering?

The question of yours that he was talking about is clearly quoted above,
though I'll have to make a few minor changes to turn it into a proper
question:

Does "the C standard actually say that the va_arg rules apply to *printf
functions?".

That is the question that you've asserted is not answerable, and I agree
with Keith both that it is trivially answerable, and that the answer is
clearly "No.".


> ... My statement is about the
> question I am considering, not about the question you are
> considering.

I see no evidence to suggest that Keith is confusing your question about
what the standard says, with your statement about the answerability of
that question. Nor that he was talking about some other question.
Perhaps you are so strongly committed to the idea that it is
unanswerable that you can't imagine anyone disagreeing with you about
that point? He wrote, before the material quoted above:

The clipped the part of his response that said "... and the answer is
no;". The first part of that sentence was about your statement that the
question is unanswerable, and asserted Keith's belief that it is
answerable. The second part is the answer that Keith considers that
question to have. I'm in full agreement with him on both points.

The standard might be taken as implying that only those rules apply. I
would consider that a misinterpretation of the words of the standard,
but it might have been the committee's intent - it's certainly not
unheard of for the committee to fail to correctly express their intent.
However, the standard most definitively fails to say that they apply.

The wording the committee actually chose is subtly different from the
va_arg() rules, without being incompatible with those rules. If they had
simply intended for those rules to apply, and nothing more, it would
have been simpler to cross-reference those rules, rather than copying
those rules, and risking the possibility of the copy being subtly
different from the original. It seems much more plausible to me that
they would do that only if making the rules subtly different was their
whole point in writing it that way.

You have a habit of seeing ambiguity in wording that isn't really
ambiguous, and of using that supposed ambiguity to justify your own best
guess as to what the committee meant, even when that meaning
incompatible with the words they chose to use to express their intent.
And since you sincerely believe the words to be ambiguous, you don't
admit that the are incompatible.

[toc] | [prev] | [next] | [standalone]

#163023

On 6/24/2021 11:28 AM, Keith Thompson wrote:
> 
> My reading of the standard is that that's certainly the intent, but
> it's not quite stated explicitly.
> 

Yes, it does. The intent of 6.2.5/9 is, among other things, is to 
postulate interchangeability of values of corresponding signed-unsigned 
types as function arguments.

No special remarks of any kind are made about variadic functions, which 
immediately closes the matter. No need to dig deeper and involve 
`va_arg` or anything else.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#163024

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 6/24/2021 11:28 AM, Keith Thompson wrote:
>> My reading of the standard is that that's certainly the intent, but
>> it's not quite stated explicitly.
>
> Yes, it does. The intent of 6.2.5/9 is, among other things, is to
> postulate interchangeability of values of corresponding
> signed-unsigned types as function arguments.
>
> No special remarks of any kind are made about variadic functions,
> which immediately closes the matter. No need to dig deeper and involve 
> `va_arg` or anything else.

N1570 6.2.5p9 says that a value that's within the range of corresponding
signed and unsigned types has the same representation in both types.
That doesn't necessarily imply interchangeability as function arguments.

It's only relevant for variadic arguments or if no prototype is visible;
otherwise an argument will be converted to the required type (and the
conversion will correctly yield the same value).

I can imagine an implementation in which signed integer arguments are
passed on the stack and unsigned integer arguments are passed in
registers, or in which they're passed in different registers.  That
would violate the stated intent given in the non-normative 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 I see no normative wording in the standard that would be violated by
such an admittedly perverse implementation.

Perhaps my phrase "not quite stated explicitly" was imprecise.  It's
stated explicitly in a footnote, but not in normative text.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#163035

On 10/6/21 12:35 PM, Andrey Tarasevich wrote:
> On 6/24/2021 11:28 AM, Keith Thompson wrote:
>>
>> My reading of the standard is that that's certainly the intent, but
>> it's not quite stated explicitly.
>>
> 
> Yes, it does. The intent of 6.2.5/9 is, among other things, is to 
> postulate interchangeability of values of corresponding signed-unsigned 
> types as function arguments.


In several locations, the standard says "The same representation and
alignment requirements are meant to imply interchangeability as
arguments to functions, return values from functions, and members of
unions."

There's several problems with that statement. Firstly, "are meant to
imply" is weasel-wording. It could have said, more simply and
forcefully, "implies". Secondly, the implication doesn't hold up under
close examination. For instance, unsigned and signed arguments with the
same alignment and same representation for positive values of the signed
type could still be passed by different methods as arguments or return
values, which would prevent them from being interchangeable. Finally,
that wording only appears in informative footnotes, not in normative text.

After raising this issue many times over a couple of decades, I finally
got confirmation from Larry Jones in 2011 (at that time, secretary of
the committee) that use of "are meant to imply" rather than "implies"
was deliberate, because it was in fact understood that no such
implication was correct. He also confirmed that the non-normative nature
of that text was also deliberate - the committee did NOT want to mandate
that the types be interchangeable, only to recommend that they be made
interchangeable.

> No special remarks of any kind are made about variadic functions, which 
> immediately closes the matter. No need to dig deeper and involve 
> `va_arg` or anything else.

In C2011, the descriptions of the printf() and scanf() family of
functions contained one notable difference from the corresponding
general requirements for functions with variable arguments:  "If any
argument is not the correct type for the corresponding conversion
specification, the behavior is undefined.".

An implementation of C2011 could therefore have provided a conforming
extension to the <va_args.h> facilities, allowing you to determine the
type of the argument corresponding to each parameter,and the
implementations of those functions could make use of that information to
fail in some fashion when the argument's type is not correct. Such an
implementation would not violate any requirement of C2011.

In n2596.pdf, the latest draft of the next version that I have access
to, that wording has been replaced:
"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."

This indicates that the committee acknowledges the validity of that
complaint, and has resolved it in a way that's not compatible with the
hypothetical implementation I've described above.

[toc] | [prev] | [next] | [standalone]

#163036

On 2021-10-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 10/6/21 12:35 PM, Andrey Tarasevich wrote:
>> On 6/24/2021 11:28 AM, Keith Thompson wrote:
>>>
>>>
>> 
>> Yes, it does. The intent of 6.2.5/9 is, among other things, is to 
>> postulate interchangeability of values of corresponding signed-unsigned 
>> types as function arguments.
>
>
> In several locations, the standard says "The same representation and
> alignment requirements are meant to imply interchangeability as
> arguments to functions, return values from functions, and members of
> unions."
>
> There's several problems with that statement. Firstly, "are meant to
> imply" is weasel-wording. It could have said, more simply and
> forcefully, "implies". Secondly, the implication doesn't hold up under
> close examination. For instance, unsigned and signed arguments with the
> same alignment and same representation for positive values of the signed
> type could still be passed by different methods as arguments or return
> values, which would prevent them from being interchangeable. Finally,
> that wording only appears in informative footnotes, not in normative text.
>
> After raising this issue many times over a couple of decades, I finally
> got confirmation from Larry Jones in 2011 (at that time, secretary of
> the committee) that use of "are meant to imply" rather than "implies"
> was deliberate, because it was in fact understood that no such
> implication was correct. He also confirmed that the non-normative nature
> of that text was also deliberate - the committee did NOT want to mandate
> that the types be interchangeable, only to recommend that they be made
> interchangeable.

Problem is that C does not defines exact type and representation.
New language have noted that mistake so they have exact representation,
even if that not corresponds to hardware.
C goed in a way to have performance and portability, which of course
you can't have both, you just have buggy programs :p
>
>> No special remarks of any kind are made about variadic functions, which 
>> immediately closes the matter. No need to dig deeper and involve 
>> `va_arg` or anything else.
>
> In C2011, the descriptions of the printf() and scanf() family of
> functions contained one notable difference from the corresponding
> general requirements for functions with variable arguments:  "If any
> argument is not the correct type for the corresponding conversion
> specification, the behavior is undefined.".
>
> An implementation of C2011 could therefore have provided a conforming
> extension to the <va_args.h> facilities, allowing you to determine the
> type of the argument corresponding to each parameter,and the
> implementations of those functions could make use of that information to
> fail in some fashion when the argument's type is not correct. Such an
> implementation would not violate any requirement of C2011.
>
> In n2596.pdf, the latest draft of the next version that I have access
> to, that wording has been replaced:
> "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."
>
> This indicates that the committee acknowledges the validity of that
> complaint, and has resolved it in a way that's not compatible with the
> hypothetical implementation I've described above.


-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#163037

On 10/6/21 6:14 PM, Branimir Maksimovic wrote:
> On 2021-10-06, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> In several locations, the standard says "The same representation and
>> alignment requirements are meant to imply interchangeability as
>> arguments to functions, return values from functions, and members of
>> unions."
>>
>> There's several problems with that statement. Firstly, "are meant to
>> imply" is weasel-wording. It could have said, more simply and
>> forcefully, "implies". Secondly, the implication doesn't hold up under
>> close examination. For instance, unsigned and signed arguments with the
>> same alignment and same representation for positive values of the signed
>> type could still be passed by different methods as arguments or return
>> values, which would prevent them from being interchangeable. Finally,
>> that wording only appears in informative footnotes, not in normative text.
>>
>> After raising this issue many times over a couple of decades, I finally
>> got confirmation from Larry Jones in 2011 (at that time, secretary of
>> the committee) that use of "are meant to imply" rather than "implies"
>> was deliberate, because it was in fact understood that no such
>> implication was correct. He also confirmed that the non-normative nature
>> of that text was also deliberate - the committee did NOT want to mandate
>> that the types be interchangeable, only to recommend that they be made
>> interchangeable.
> 
> Problem is that C does not defines exact type and representation.
> New language have noted that mistake so they have exact representation,
> even if that not corresponds to hardware.
> C goed in a way to have performance and portability, which of course
> you can't have both, you just have buggy programs :p

No, that's a distinct issue. If the C standard were changed to
explicitly specify the exact representation of every data type, and no
other changes were made, it would still be perfectly legal, for
instance, for an implementation to use different methods for passing
signed and unsigned arguments; on an implementation that did so, they
would not be interchangeable as arguments of or return values from
functions, not even for values that are representable in both types.

It's also not necessarily a problem with C. Different languages are
designed for different purposes. C was designed to be efficiently
implementable almost everywhere - at the cost of making it more
difficult to port code from one implementation to another. Other
languages consider it more important to be able to port code between any
two implementations of the language, at the cost of the language not
being efficiently implementable on all platforms.
C has added the size-named integer types, which mitigates this problem
somewhat.

[toc] | [prev] | [next] | [standalone]

#163038

On 2021-10-07, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> C has added the size-named integer types, which mitigates this problem
> somewhat.
I see. Thanks.

-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

[toc] | [prev] | [next] | [standalone]

#161486

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [... on printing various integer types ...]
<cut>
>>     printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX);
>
> The cast in the last line is not needed.
<cut>
> The description of how type promotion works is right, however a
> cast is still not needed there.  The reason is that values given
> as variadic arguments are allowed to be the corresponding signed
> or unsigned version of the type used to get the value, and that
> will work as long as the value is in the set of values common to
> both types.  If an unsigned short promotes to int, then its value
> is guaranteed to be in the set of values representable by both
> int and unsigned int, and hence using %u for an uncasted unsigned
> short is always safe.

It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the 'u'
conversion specifier:

  "o,u,x,X The unsigned int argument is..."

and, later, paragraph 9 says

  "... If any argument is not the correct type for the corresponding
  conversion specification, the behavior is undefined."

So I am left wondering how one can know that int (the promoted type when
no cast is used) is "the correct type" for the 'u' conversion
specification.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#161487

On Friday, 25 June 2021 at 00:34:58 UTC+3, Ben Bacarisse wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes: 
> 
> > Keith Thompson <Keith.S.T...@gmail.com> writes: 
> > 
> > [... on printing various integer types ...]
> <cut>
> >> printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX); 
> > 
> > The cast in the last line is not needed.
> <cut>
> > The description of how type promotion works is right, however a 
> > cast is still not needed there. The reason is that values given 
> > as variadic arguments are allowed to be the corresponding signed 
> > or unsigned version of the type used to get the value, and that 
> > will work as long as the value is in the set of values common to 
> > both types. If an unsigned short promotes to int, then its value 
> > is guaranteed to be in the set of values representable by both 
> > int and unsigned int, and hence using %u for an uncasted unsigned 
> > short is always safe.
> It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the 'u' 
> conversion specifier: 
> 
> "o,u,x,X The unsigned int argument is..." 
> 
> and, later, paragraph 9 says 
> 
> "... If any argument is not the correct type for the corresponding 
> conversion specification, the behavior is undefined." 
> 
> So I am left wondering how one can know that int (the promoted type when 
> no cast is used) is "the correct type" for the 'u' conversion 
> specification. 

Yes it is strange. IIRC the constant USHRT_MAX may be of type
signed int or unsigned int but can not be of type unsigned short.

[toc] | [prev] | [next] | [standalone]

#161488

Öö Tiib <ootiib@hot.ee> writes:
> On Friday, 25 June 2021 at 00:34:58 UTC+3, Ben Bacarisse wrote:
>> Tim Rentsch <tr.1...@z991.linuxsc.com> writes: 
>> > Keith Thompson <Keith.S.T...@gmail.com> writes: 
>> > 
>> > [... on printing various integer types ...]
>> <cut>
>> >> printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX); 
>> > 
>> > The cast in the last line is not needed.
>> <cut>
>> > The description of how type promotion works is right, however a 
>> > cast is still not needed there. The reason is that values given 
>> > as variadic arguments are allowed to be the corresponding signed 
>> > or unsigned version of the type used to get the value, and that 
>> > will work as long as the value is in the set of values common to 
>> > both types. If an unsigned short promotes to int, then its value 
>> > is guaranteed to be in the set of values representable by both 
>> > int and unsigned int, and hence using %u for an uncasted unsigned 
>> > short is always safe.
>> It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the 'u' 
>> conversion specifier: 
>> 
>> "o,u,x,X The unsigned int argument is..." 
>> 
>> and, later, paragraph 9 says 
>> 
>> "... If any argument is not the correct type for the corresponding 
>> conversion specification, the behavior is undefined." 
>> 
>> So I am left wondering how one can know that int (the promoted type when 
>> no cast is used) is "the correct type" for the 'u' conversion 
>> specification. 
>
> Yes it is strange. IIRC the constant USHRT_MAX may be of type
> signed int or unsigned int but can not be of type unsigned short.

Correct.  Which means that if you want to print the value of USHRT_MAX
safely, you can do:

    printf("USHRT_MAX = %u\n", (unsigned)USHRT_MAX);

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

[toc] | [prev] | [next] | [standalone]

#161871

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [... on printing various integer types ...]
>
> <cut>
>
>>>     printf("USHRT_MAX : %u\n", (unsigned)USHRT_MAX);
>>
>> The cast in the last line is not needed.
>
> <cut>
>
>> The description of how type promotion works is right, however a
>> cast is still not needed there.  The reason is that values given
>> as variadic arguments are allowed to be the corresponding signed
>> or unsigned version of the type used to get the value, and that
>> will work as long as the value is in the set of values common to
>> both types.  If an unsigned short promotes to int, then its value
>> is guaranteed to be in the set of values representable by both
>> int and unsigned int, and hence using %u for an uncasted unsigned
>> short is always safe.
>
> It's safe (in practical terms) but 7.21.6.1 paragraph 8 says of the
> 'u' conversion specifier:
>
>   "o,u,x,X The unsigned int argument is..."
>
> and, later, paragraph 9 says
>
>   "... If any argument is not the correct type for the corresponding
>   conversion specification, the behavior is undefined."
>
> So I am left wondering how one can know that int (the promoted type
> when no cast is used) is "the correct type" for the 'u' conversion
> specification.

I believe the rule about variadic arguments applying to printf
arguments is both what was intended and how the C standard is
generally read by others, including in particular implementors.
Consider two possibilities:

One: the rules for type correctness for printf arguments are
defined only by the somewhat vague phrase "the correct type" and
are different from the rules for other functions taking variadic
arguments;  or

Two: the rules for type correctness for printf arguments are the
same as the rules for type correctness for other functions taking
variadic arguments (taking into account of course that different
specifiers imply different nominal argument types).

For completeness I should mention the reference Keith Thompson
pointed out, 7.16.1.1 (paragraph 2), that gives this rule for
the 'va_arg' macro, ie, that the corresponding unsigned type
is okay for a signed type specification, and vice versa, provided
the argument value given is representable in both types.

Are the rules for type correctness for printf idiosyncratic and
specific to printf, or are they the same as other variadic
functions?  To me the second case seems much more likely.

Note that both gcc and clang, running with a -Wformat option
given, accept with no diagnostic a signed argument for an
unsigned specifier, and vice versa.

At this point I realized that I haven't really responded to your
implied question about "how one can know that", for example, an
int can be given for a %u conversion sequence.  At least right
now I think the best answer I can give you is to think like an
implementor.  The people who write the C standard aren't lawyers,
they are regular software developers, with a fair amount of
implementation experience.  They aren't thinking mainly about the
words.  They are, I belive, thinking first in terms of how things
are implemented, and only later about how to express that in
normal written language.  If we think about it in terms of
implementation the relationship seems pretty straightforward.
The allowance for unsigned/signed interchangeability is given
explicitly in the description for va_arg;  usually the C standard
avoids giving the same rule in more than one place, so it isn't
surprising that it wouldn't be repeated in the description of
arguments for *printf functions, but instead just referred to by
the phrase "the correct type".  Does that make sense?

Incidentally, in C90 neither the sentence about "the correct type"
nor the extra type rules for va_arg were present.  Both were added
in C99.  I don't know whether that has any bearing on the question
at hand, but it's an interesting historical coincidence.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web