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

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

Sequencing guarantees for macro versions of standard functions

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

Contents

  Sequencing guarantees for macro versions of standard functions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-20 15:59 -0800
    Re: Sequencing guarantees for macro versions of standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-20 16:35 -0800
      Re: Sequencing guarantees for macro versions of standard functions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-23 14:38 -0800
        Re: Sequencing guarantees for macro versions of standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-23 19:36 -0800
          Re: Sequencing guarantees for macro versions of standard functions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-23 19:56 -0800
            Re: Sequencing guarantees for macro versions of standard functions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-23 19:58 -0800
              Re: Sequencing guarantees for macro versions of standard functions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-23 23:50 -0800
              Re: Sequencing guarantees for macro versions of standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-24 07:27 -0800
          Re: Sequencing guarantees for macro versions of standard functions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-23 23:49 -0800
            Re: Sequencing guarantees for macro versions of standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-24 07:31 -0800
              Re: Sequencing guarantees for macro versions of standard functions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-24 13:18 -0800
                Re: Sequencing guarantees for macro versions of standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-29 03:36 -0800

#164496 — Sequencing guarantees for macro versions of standard functions

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

[toc] | [next] | [standalone]

#164497

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?

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

#164559

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

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

#164567

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.

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

#164568

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

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

#164569

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

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

#164571

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

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

#164578

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.

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

#164570

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

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

#164579

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.

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

#164594

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

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

#164710

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.

[toc] | [prev] | [standalone]

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

csiph-web