7.1.4 Use of library functions
http://port70.net/~nsz/c/c11/n1570.html#7.1.4p1

7.1.4/1 states that any function declared in a standard header can be
additionally implemented as a function-like macro (unless explicitly
stated otherwise)

"[...] Any function declared in a header may be additionally implemented
as a function-like macro defined in the header [...]"

It also gives some guarantees about the arguments being evaluated
exactly once

"[...] Any invocation of a library function that is implemented as a
macro shall expand to code that evaluates each of its arguments exactly
once, fully protected by parentheses where necessary, so it is generally
safe to use arbitrary expressions as arguments. [...]"

However, that last statement is accompanied by a footnote

"186) Such macros might not contain the sequence points that the
corresponding function calls do"

It appears that this footnote is intended to draw attention to the fact
that normative text does not require macro implementations to fully
match the sequencing properties of a "normal" implementation of the same
standard function.

Is that really the case?

Consider the following example

double x = 1.5;
x = modf(x, &x);

This is fine in case `modf` is actually a function. But does the
standard intend to guarantee that this is specified and defined even if
`modf` is implemented as a macro? I would expect so, and it is quite
possible that the following passage

"[...] Likewise, those function-like macros described in the following
subclauses may be invoked in an expression anywhere a function with a
compatible return type could be called. [...]"

is intended to guarantee exactly that.

But still, what exactly are they trying to point out in footnote 186?

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> 7.1.4 Use of library functions
> http://port70.net/~nsz/c/c11/n1570.html#7.1.4p1
>
> 7.1.4/1 states that any function declared in a standard header can be
> additionally implemented as a function-like macro (unless explicitly
> stated otherwise)
>
> "[...] Any function declared in a header may be additionally
> implemented as a function-like macro defined in the header [...]"
>
> It also gives some guarantees about the arguments being evaluated
> exactly once
>
> "[...] Any invocation of a library function that is implemented as a
> macro shall expand to code that evaluates each of its arguments
> exactly once, fully protected by parentheses where necessary, so it is
> generally safe to use arbitrary expressions as arguments. [...]"
>
> However, that last statement is accompanied by a footnote
>
> "186) Such macros might not contain the sequence points that the
> corresponding function calls do"
>
> It appears that this footnote is intended to draw attention to the
> fact that normative text does not require macro implementations to
> fully match the sequencing properties of a "normal" implementation of
> the same standard function.
>
> Is that really the case?

Yes.

> Consider the following example
>
> double x = 1.5;
> x = modf(x, &x);
>
> This is fine in case `modf` is actually a function. But does the
> standard intend to guarantee that this is specified and defined even
> if `modf` is implemented as a macro?

No.

> I would expect so, and it is quite possible that the following passage
>
> "[...] Likewise, those function-like macros described in the following
> subclauses may be invoked in an expression anywhere a function with a
> compatible return type could be called. [...]"
>
> is intended to guarantee exactly that.

The quoted passage guarantees what it says: such function-like
macros may be /invoked/ anywhere their corresponding functions
could. It does /not/ guarantee that such invocations will work
if there are sequencing issues.

> But still, what exactly are they trying to point out in footnote 186?

If not having the same sequencing guarantees might cause a
problem (ie, if a "call" might invoke a macro rather than calling
a function), avoid using a function call expression that might
invoke a macro, as for example in this particular case

x = (modf)( x, &x );

so that we're sure an actual function call takes place. Hence we
know there will be no sequencing problems. Make sense?

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
[...]
>> Consider the following example
>>
>> double x = 1.5;
>> x = modf(x, &x);
>>
>> This is fine in case `modf` is actually a function. But does the
>> standard intend to guarantee that this is specified and defined even
>> if `modf` is implemented as a macro?
>
> No.
>
>> I would expect so, and it is quite possible that the following passage
>>
>> "[...] Likewise, those function-like macros described in the following
>> subclauses may be invoked in an expression anywhere a function with a
>> compatible return type could be called. [...]"
>>
>> is intended to guarantee exactly that.
>
> The quoted passage guarantees what it says: such function-like
> macros may be /invoked/ anywhere their corresponding functions
> could. It does /not/ guarantee that such invocations will work
> if there are sequencing issues.
>
>> But still, what exactly are they trying to point out in footnote 186?
>
> If not having the same sequencing guarantees might cause a
> problem (ie, if a "call" might invoke a macro rather than calling
> a function), avoid using a function call expression that might
> invoke a macro, as for example in this particular case
>
> x = (modf)( x, &x );
>
> so that we're sure an actual function call takes place. Hence we
> know there will be no sequencing problems. Make sense?

Or

x = modf(x, &y);
x = y;

(I'm already a bit uncomfortable with x = (modf)(x, &x), though I know
it's well defined.)

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

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>
> [...]
>
>>> Consider the following example
>>>
>>> double x = 1.5;
>>> x = modf(x, &x);
>>>
>>> This is fine in case `modf` is actually a function. But does the
>>> standard intend to guarantee that this is specified and defined even
>>> if `modf` is implemented as a macro?
>>
>> No.
>>
>>> I would expect so, and it is quite possible that the following passage
>>>
>>> "[...] Likewise, those function-like macros described in the following
>>> subclauses may be invoked in an expression anywhere a function with a
>>> compatible return type could be called. [...]"
>>>
>>> is intended to guarantee exactly that.
>>
>> The quoted passage guarantees what it says: such function-like
>> macros may be /invoked/ anywhere their corresponding functions
>> could. It does /not/ guarantee that such invocations will work
>> if there are sequencing issues.
>>
>>> But still, what exactly are they trying to point out in footnote 186?
>>
>> If not having the same sequencing guarantees might cause a
>> problem (ie, if a "call" might invoke a macro rather than calling
>> a function), avoid using a function call expression that might
>> invoke a macro, as for example in this particular case
>>
>> x = (modf)( x, &x );
>>
>> so that we're sure an actual function call takes place. Hence we
>> know there will be no sequencing problems. Make sense?
>
> Or
>
> x = modf(x, &y);
> x = y;
>
> (I'm already a bit uncomfortable with x = (modf)(x, &x), though
> I know it's well defined.)

I understand having a queasy reaction to 'x = (modf)(x, &x)', and
to some degree I have such a reaction myself. I deliberately
chose not to comment about that, since what was being asked about
is only about sequencing issues in macros vs functions.

However, the suggested rewrite has different semantics than the
previous single assignment with function call. If we want to
keep the same semantics but still be able to use the macro
form (but without any sequencing issues), a different writing
is needed, as for example

x = modf( x, (double[]){ 0 } );

Writing the call this way should make it obvious that the value
stored in/through the second argument is ignored and discarded.

On 1/23/2022 7:36 PM, Tim Rentsch wrote:
>
> However, the suggested rewrite has different semantics than the
> previous single assignment with function call. If we want to
> keep the same semantics but still be able to use the macro
> form (but without any sequencing issues), a different writing
> is needed, as for example
>
> x = modf( x, (double[]){ 0 } );
>
> Writing the call this way should make it obvious that the value
> stored in/through the second argument is ignored and discarded.

That would be

x = modf( x, &(double[]){ 0 } );

--
Best regards,
Andrey Tarasevich

On 1/23/2022 7:56 PM, Andrey Tarasevich wrote:
> On 1/23/2022 7:36 PM, Tim Rentsch wrote:
>>
>> However, the suggested rewrite has different semantics than the
>> previous single assignment with function call.  If we want to
>> keep the same semantics but still be able to use the macro
>> form (but without any sequencing issues), a different writing
>> is needed, as for example
>>
>>      x = modf( x, (double[]){ 0 } );
>>
>> Writing the call this way should make it obvious that the value
>> stored in/through the second argument is ignored and discarded.
>
> That would be
>
>       x = modf( x, &(double[]){ 0 } );
>

Opps, my sitake. Sorry, I missed the `[]` part.

Of course, your original variant is correct. Although I don't see the
point of bringing arrays into the picture. One can just do

x = modf( x, &(double){ 0 } );

--
Best regards,
Andrey Tarasevich

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:
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> [...]
>>
>>>> Consider the following example
>>>>
>>>> double x = 1.5;
>>>> x = modf(x, &x);
>>>>
>>>> This is fine in case `modf` is actually a function. But does the
>>>> standard intend to guarantee that this is specified and defined even
>>>> if `modf` is implemented as a macro?
>>>
>>> No.
>>>
>>>> I would expect so, and it is quite possible that the following passage
>>>>
>>>> "[...] Likewise, those function-like macros described in the following
>>>> subclauses may be invoked in an expression anywhere a function with a
>>>> compatible return type could be called. [...]"
>>>>
>>>> is intended to guarantee exactly that.
>>>
>>> The quoted passage guarantees what it says: such function-like
>>> macros may be /invoked/ anywhere their corresponding functions
>>> could. It does /not/ guarantee that such invocations will work
>>> if there are sequencing issues.
>>>
>>>> But still, what exactly are they trying to point out in footnote 186?
>>>
>>> If not having the same sequencing guarantees might cause a
>>> problem (ie, if a "call" might invoke a macro rather than calling
>>> a function), avoid using a function call expression that might
>>> invoke a macro, as for example in this particular case
>>>
>>> x = (modf)( x, &x );
>>>
>>> so that we're sure an actual function call takes place. Hence we
>>> know there will be no sequencing problems. Make sense?
>>
>> Or
>>
>> x = modf(x, &y);
>> x = y;
>>
>> (I'm already a bit uncomfortable with x = (modf)(x, &x), though
>> I know it's well defined.)
>
> I understand having a queasy reaction to 'x = (modf)(x, &x)', and
> to some degree I have such a reaction myself. I deliberately
> chose not to comment about that, since what was being asked about
> is only about sequencing issues in macros vs functions.
>
> However, the suggested rewrite has different semantics than the
> previous single assignment with function call. If we want to
> keep the same semantics but still be able to use the macro
> form (but without any sequencing issues), a different writing
> is needed, as for example
>
> x = modf( x, (double[]){ 0 } );
>
> Writing the call this way should make it obvious that the value
> stored in/through the second argument is ignored and discarded.

Right, I should have paid closer attention to the semantics of modf()
(which I don't think I've ever used "in anger").

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

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 1/23/2022 7:56 PM, Andrey Tarasevich wrote:
>> On 1/23/2022 7:36 PM, Tim Rentsch wrote:
>>>
>>> However, the suggested rewrite has different semantics than the
>>> previous single assignment with function call.  If we want to
>>> keep the same semantics but still be able to use the macro
>>> form (but without any sequencing issues), a different writing
>>> is needed, as for example
>>>
>>>      x = modf( x, (double[]){ 0 } );
>>>
>>> Writing the call this way should make it obvious that the value
>>> stored in/through the second argument is ignored and discarded.
>> That would be
>>       x = modf( x, &(double[]){ 0 } );
>>
>
> Opps, my sitake. Sorry, I missed the `[]` part.
>
> Of course, your original variant is correct. Although I don't see the
> point of bringing arrays into the picture. One can just do
>
> x = modf( x, &(double){ 0 } );

My preference would be:

double ignored;
x = modf(x, &ignored);

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

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 1/23/2022 7:56 PM, Andrey Tarasevich wrote:
>
>> On 1/23/2022 7:36 PM, Tim Rentsch wrote:
>>
>>> However, the suggested rewrite has different semantics than the
>>> previous single assignment with function call. If we want to
>>> keep the same semantics but still be able to use the macro
>>> form (but without any sequencing issues), a different writing
>>> is needed, as for example
>>>
>>> x = modf( x, (double[]){ 0 } );
>>>
>>> Writing the call this way should make it obvious that the value
>>> stored in/through the second argument is ignored and discarded.
>>
>> That would be
>>
>> x = modf( x, &(double[]){ 0 } );
>
> Opps, my sitake. Sorry, I missed the `[]` part.
>
> Of course, your original variant is correct. Although I don't see
> the point of bringing arrays into the picture. One can just do
>
> x = modf( x, &(double){ 0 } );

For no particular reason I can point to (no pun intended), in
situations like this one I normally use the array type form in
preference to the & form. I find it easier to digest, and also
think it expresses more directly what I want to convey. I'm sure
many people would normally use the & form, and I'm okay with that
choice, but it doesn't change my choice.

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:
>>>
>>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>>
>>> [...]
>>>
>>>>> Consider the following example
>>>>>
>>>>> double x = 1.5;
>>>>> x = modf(x, &x);
>>>>>
>>>>> This is fine in case `modf` is actually a function. But does the
>>>>> standard intend to guarantee that this is specified and defined even
>>>>> if `modf` is implemented as a macro?
>>>>
>>>> No.
>>>>
>>>>> I would expect so, and it is quite possible that the following passage
>>>>>
>>>>> "[...] Likewise, those function-like macros described in the following
>>>>> subclauses may be invoked in an expression anywhere a function with a
>>>>> compatible return type could be called. [...]"
>>>>>
>>>>> is intended to guarantee exactly that.
>>>>
>>>> The quoted passage guarantees what it says: such function-like
>>>> macros may be /invoked/ anywhere their corresponding functions
>>>> could. It does /not/ guarantee that such invocations will work
>>>> if there are sequencing issues.
>>>>
>>>>> But still, what exactly are they trying to point out in footnote 186?
>>>>
>>>> If not having the same sequencing guarantees might cause a
>>>> problem (ie, if a "call" might invoke a macro rather than calling
>>>> a function), avoid using a function call expression that might
>>>> invoke a macro, as for example in this particular case
>>>>
>>>> x = (modf)( x, &x );
>>>>
>>>> so that we're sure an actual function call takes place. Hence we
>>>> know there will be no sequencing problems. Make sense?
>>>
>>> Or
>>>
>>> x = modf(x, &y);
>>> x = y;
>>>
>>> (I'm already a bit uncomfortable with x = (modf)(x, &x), though
>>> I know it's well defined.)
>>
>> I understand having a queasy reaction to 'x = (modf)(x, &x)', and
>> to some degree I have such a reaction myself. I deliberately
>> chose not to comment about that, since what was being asked about
>> is only about sequencing issues in macros vs functions.
>>
>> However, the suggested rewrite has different semantics than the
>> previous single assignment with function call. If we want to
>> keep the same semantics but still be able to use the macro
>> form (but without any sequencing issues), a different writing
>> is needed, as for example
>>
>> x = modf( x, (double[]){ 0 } );
>>
>> Writing the call this way should make it obvious that the value
>> stored in/through the second argument is ignored and discarded.
>
> Right, I should have paid closer attention to the semantics of modf()
> (which I don't think I've ever used "in anger").

Why do you make the "in anger" comment? I couldn't find any
connection to earlier remarks in this thread.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> Right, I should have paid closer attention to the semantics of modf()
>> (which I don't think I've ever used "in anger").
>
> Why do you make the "in anger" comment? I couldn't find any
> connection to earlier remarks in this thread.

It's a figure of speech. Quoting a comment I found on Hacker News:

To "use something in anger" is a phrase, meaning to use something
"for real" - in production, etc. rather than just to try it out.

No actual anger is implied.

https://news.ycombinator.com/item?id=10806244

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

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:
>
> [...]
>
>>> Right, I should have paid closer attention to the semantics of modf()
>>> (which I don't think I've ever used "in anger").
>>
>> Why do you make the "in anger" comment? I couldn't find any
>> connection to earlier remarks in this thread.
>
> It's a figure of speech. Quoting a comment I found on Hacker News:
>
> To "use something in anger" is a phrase, meaning to use something
> "for real" - in production, etc. rather than just to try it out.
>
> No actual anger is implied.

I see. I wasn't aware of that idiom.