Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164570
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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