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


Groups > comp.lang.c > #164570

Re: Sequencing guarantees for macro versions of standard functions

From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.lang.c
Subject Re: Sequencing guarantees for macro versions of standard functions
Date 2022-01-23 23:49 -0800
Organization None to speak of
Message-ID <87r18xo9o6.fsf@nosuchdomain.example.com> (permalink)
References <ssct1k$651$1@dont-email.me> <86k0euq62t.fsf@linuxsc.com> <87lez6xeld.fsf@nosuchdomain.example.com> <868rv5oldy.fsf@linuxsc.com>

Show all headers | View raw


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

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