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?

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

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.

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

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

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.

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

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.

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