Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Sequencing guarantees for macro versions of standard functions
Date: Sun, 23 Jan 2022 14:38:22 -0800
Organization: None to speak of
Lines: 51
Message-ID: <87lez6xeld.fsf@nosuchdomain.example.com>
References: <ssct1k$651$1@dont-email.me> <86k0euq62t.fsf@linuxsc.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="bf212cab00378f73488330ba3dd56683"; logging-data="3010"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/xP3qlF6eSJeFE+kC0WkkR"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:+7s3Aj6awt1/wCUKjufCqDTDeGU= sha1:ViVRTPYHz/NWyJS25H/v8ZR5v48=
Xref: csiph.com comp.lang.c: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 */