Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Sequencing guarantees for macro versions of standard functions Date: Sun, 23 Jan 2022 19:36:25 -0800 Organization: A noiseless patient Spider Lines: 67 Message-ID: <868rv5oldy.fsf@linuxsc.com> References: <86k0euq62t.fsf@linuxsc.com> <87lez6xeld.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d742d26243a9575adb46fc0e29496190"; logging-data="742"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/tigCEgDGjA20vEq8Oedes79qqA9a82JM=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:zkbRu97cipi6t2CqmBr+c9WUp0Y= sha1:cA5LXgdHZpRd6COGnwqvCAoZEQo= Xref: csiph.com comp.lang.c:164567 Keith Thompson writes: > Tim Rentsch writes: > >> Andrey Tarasevich 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.