MSC38-C. Do not treat a predefined identifier as an object if it might only be implemented as a macro

Ah, I thought the standard meant referring to the function underlying the assert macro, but looking at it again, it does seem to mean using a function called assert.

But then, wouldn't your code above necessarily not compile because the assert function identifier is undefined? I feel like ub14 would be triggered by something like this:

#include <assert.h>

// suppose the following is the definition of the assert()
// macro in <assert.h> and there is no function with the
// same name:
// #define assert(expr)   \
//   ((expr) ? (void)0 \
//           : (void)fprintf(stderr, "Assertion failed: %s:%d (%s): %s\n", \
//                            __FILE__, __LINE__, __func__, #expr))
//

#undef assert        // assert() macro suppressed

// Define a function assert
void assert(int i) {
     /* verifacation... */
}

void g(int i) {
  assert(i);     // calling function assert()
}

C99 (n1256), S7.2 says:

The assert macro shall be implemented as a macro, not as an actual function. If the macro definition is suppressed in order to access an actual function, the behavior is undefined.

As I see it, the question of whether the 1st NCCE invokes undefined behavior is open to interpretation. Does the text "in order to access an actual function" imply that

1. the dveloper thinks the assert() macro is covering an implementation-defined assert function, and they wish to access the function w/o using the macro?

or

2. the developer creates their own assert() function and suppresses the assert() macro in order to access their own function.

The 1st NCCE falls under case (2), and I suspect (but am not sure that) the standard meant case (1).

The problem this guideline attempts to warn against is accessing (not just redefining) the symbols underlying the handful of identifiers that may only be implemented as macros (and not necessarily as functions/objects with the same name). The problem, in all cases, is the same as the one mentioned in my comment Re: MSC38-C. Do not treat as an object any predefined identifier that might be implemented as a macro: that the underlying object or function may not exist. The effect of accessing it is a compilation or linker error. It is a compilation when no matching declaration exists, and it is a linker error when a matching declaration exists for which the program (or the C library) does not provide a definition.

An example involving errno is:

#include <errno.h>
#undef errno

int error() {
  // accessing the underlying object when it may not exist
  return errno;
}

Note that neither NCCE in this guideline demonstrates the problem the guideline is about. They both declare an identifier with the same name as one of the reserved names (which may be a bad idea but it will not cause a problem on any implementation).

As I have been trying to say all along, the noncompliant examples should demonstrate the real risks of violating the language rules and they should be reproducible with popular compilers. The NCCE involving errno I give above clearly illustrates the problem when compiled with gcc on Linux:

z.c: In function ‘error’:
z.c:5: error: ‘errno’ undeclared (first use in this function)
z.c:5: error: (Each undeclared identifier is reported only once
z.c:5: error: for each function it appears in.)

The assert example I gave in my earlier comments produces similar output:

z.c: In function ‘f’:
z.c:13: error: ‘assert’ undeclared (first use in this function)
z.c:13: error: (Each undeclared identifier is reported only once
z.c:13: error: for each function it appears in.)

A slightly modified example involving errno that demonstrates a linker error looks like this:

#include <errno.h>
#undef errno

extern int errno;

int error() {
  return errno;
}

Compiling and linking it with gcc on Linux/x64 produces the following output:

/usr/bin/ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in /tmp/ccg4BUxc.o
/lib64/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status

The way the title reads, to me, is incorrect.  The standard explicitly says that you can suppress library-defined function macros in the general case (7.1.4p1):

Any function declared in a header may be additionally implemented as a function-like macro defined in the header, so if a library function is declared explicitly when its header is included, one of the techniques shown below can be used to ensure the declaration is not affected by such a macro. Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses, because the name is then not followed by the left parenthesis that indicates expansion of a macro function name. For the same syntactic reason, it is permitted to take the address of a library function even if it is also defined as a macro.¹⁸⁵

185) This means that an implementation shall provide an actual function for each library function, even if it also provides a macro for that function.

The title seems to prohibit this behavior generally instead of in the few specific cases outlined in the rule.  However, I'm at a loss for an improved title.