Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164559
| 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> |
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 | 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