Reply to thread

Message: [QUOTE="Keith Thompson, post: 5076599"] puts may be a *function-like* macro. Even if it is, the name `puts` not followed by a `(` will not expand that macro; it's a function designator referring to the standard `puts` function. The standard doesn't permit names of library functions to be redefined as object-like macros. If it did, this: (puts)("hello"); would not reliably call the actual puts function. In fact, `a = puts;` is not merely implementation-defined or undefined behavior, it's a constraint violation. There is no implicit conversion from function pointers to integers. The assignment violates the constraint specified in N1570 6.5.16.1 regarding the permitted operands of a simple assignment. After issuing the required diagnostic, an implementation *may* choose to generate code equivalent to a conversion, as if you had written: a = (int)puts; But that conversion has undefined behavior, simply because the standard does not define the behavior of such a conversion. It's very likely that your compiler copies the representation of a pointer to puts, or a part of it, into a. But (a) you shouldn't depend on that, and (b) there's very little you can usefully do with the result anyway. The memcpy() calls are likewise constraint violations, because there's no implicit conversion from a function pointer to void*. [/QUOTE]