5 ms·

Well, no, in this test program memcpy is declared as having no arguments and it has to be called with no arguments. It's perfectly consistent, unless memcpy is

Well, no, in this test program memcpy is declared as having no arguments and it has to be called with no arguments. It's perfectly consistent, unless memcpy is so magical that some specific undefined behaviour is allowed (not likely). The actual test comes later: the real memcpy with three arguments, if it exists, is mislinked into the test executable; if memcpy cannot be found linking fails. The test program would hopefully crash badly in case it is actually run, but the test is not about memcpy behaviour or about what the parameters of memcpy are.

Rusky 6y ago
> It's perfectly consistent, unless memcpy is so magical that some specific undefined behaviour is allowed (not likely). memcpy is so magical that some specific undefined behavior is allowed. It's more than a mere library function- it's closer to a compiler intrinsic.
- cygx 6y ago
  As far as the standard goes, it's just a name you're not allowed to define yourself with external linkage.
acqq 6y ago
I agree. If the compiler authors make some additional "magic", they are also responsible to "unmagic" the code which checks: "if memcpy is defined as having no arguments, and then a call to it is compiled (the call is never executed), will the memcpy routine from the standard library (which must be linkable only using the name) be successfully linked?"
jcranmer 6y ago
It's not the declaration of memcpy that matters, it's the definition. And the definition of memcpy is given by the C standard. In the case of external functions, it's the user's responsibility to ensure that the declaration is compatible with the definition. If you want to use a non-standard function that coincidentally happens to be memcpy, you have to use special compiler flags to inform the compiler that C library semantics are not in effect (e.g., -ffreestanding). Of course, the entire point of these checks is to figure out if the C library has these functions in the first place, so using these options during the tests would defeat the purpose. > The actual test comes later: the real memcpy with three arguments, if it exists, is mislinked into the test executable; if memcpy cannot be found linking fails. The actual test both compiles and links the executable, although it (obviously) doesn't attempt to run it. Whether it fails in the compile or the link step is immaterial to the test, as it fails either way.

Rusky 6y ago

> It's perfectly consistent, unless memcpy is so magical that some specific undefined behaviour is allowed (not likely). memcpy is so magical that some specific undefined behavior is allowed. It's more than a mere library function- it's closer to a compiler intrinsic.

cygx 6y ago
As far as the standard goes, it's just a name you're not allowed to define yourself with external linkage.

acqq 6y ago

I agree. If the compiler authors make some additional "magic", they are also responsible to "unmagic" the code which checks: "if memcpy is defined as having no arguments, and then a call to it is compiled (the call is never executed), will the memcpy routine from the standard library (which must be linkable only using the name) be successfully linked?"

jcranmer 6y ago

It's not the declaration of memcpy that matters, it's the definition. And the definition of memcpy is given by the C standard. In the case of external functions, it's the user's responsibility to ensure that the declaration is compatible with the definition. If you want to use a non-standard function that coincidentally happens to be memcpy, you have to use special compiler flags to inform the compiler that C library semantics are not in effect (e.g., -ffreestanding). Of course, the entire point of these checks is to figure out if the C library has these functions in the first place, so using these options during the tests would defeat the purpose. > The actual test comes later: the real memcpy with three arguments, if it exists, is mislinked into the test executable; if memcpy cannot be found linking fails. The actual test both compiles and links the executable, although it (obviously) doesn't attempt to run it. Whether it fails in the compile or the link step is immaterial to the test, as it fails either way.