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


Groups > comp.lang.c > #164559

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 14:38 -0800
Organization None to speak of
Message-ID <87lez6xeld.fsf@nosuchdomain.example.com> (permalink)
References <ssct1k$651$1@dont-email.me> <86k0euq62t.fsf@linuxsc.com>

Show all headers | View raw


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

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