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


Groups > comp.lang.c > #164567

Re: Sequencing guarantees for macro versions of standard functions

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.lang.c
Subject Re: Sequencing guarantees for macro versions of standard functions
Date 2022-01-23 19:36 -0800
Organization A noiseless patient Spider
Message-ID <868rv5oldy.fsf@linuxsc.com> (permalink)
References <ssct1k$651$1@dont-email.me> <86k0euq62t.fsf@linuxsc.com> <87lez6xeld.fsf@nosuchdomain.example.com>

Show all headers | View raw


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.

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web