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


Groups > comp.lang.c > #164496

Sequencing guarantees for macro versions of standard functions

From Andrey Tarasevich <andreytarasevich@hotmail.com>
Newsgroups comp.lang.c
Subject Sequencing guarantees for macro versions of standard functions
Date 2022-01-20 15:59 -0800
Organization A noiseless patient Spider
Message-ID <ssct1k$651$1@dont-email.me> (permalink)

Show all headers | View raw


7.1.4 Use of library functions
http://port70.net/~nsz/c/c11/n1570.html#7.1.4p1

7.1.4/1 states that any function declared in a standard header can be 
additionally implemented as a function-like macro (unless explicitly 
stated otherwise)

"[...] Any function declared in a header may be additionally implemented 
as a function-like macro defined in the header [...]"

It also gives some guarantees about the arguments being evaluated 
exactly once

"[...] Any invocation of a library function that is implemented as a 
macro shall expand to code that evaluates each of its arguments exactly 
once, fully protected by parentheses where necessary, so it is generally 
safe to use arbitrary expressions as arguments. [...]"

However, that last statement is accompanied by a footnote

"186) Such macros might not contain the sequence points that the 
corresponding function calls do"

It appears that this footnote is intended to draw attention to the fact 
that normative text does not require macro implementations to fully 
match the sequencing properties of a "normal" implementation of the same 
standard function.

Is that really the case?

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? 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.

But still, what exactly are they trying to point out in footnote 186?

-- 
Best regards,
Andrey Tarasevich

Back to comp.lang.c | Previous | NextNext 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