Hacker News Reader

Comment by pornel | Hacker News Reader

If you do only minimal things, you will have fragile builds. The hacks are there not because people like adding complex code for no reason, but they're scars from broken builds.

For example, requirements for what has to be static and what dynamic are different on Linux (distros want unbundling) and macOS and Windows (you can link to handful of things that ship with the OS). macOS is especially annoying, because if you're not careful, you'll link dynamically to homebrew's non-permanent locations. `find_package` doesn't do the right thing without clever non-minimal things around it.

View on HN

Having worked on compilers, I can honestly say that autotools' attempts to be helpful are more often the cause of the trouble than fixing anything broken.

For example, it checks for memcpy by writing this program:

  void memcpy(void);
  int main() { (void)memcpy(); }

and checking if it compiles. Which is of course illegal and completely nonsensical C code that no one would ever write. It is not entirely unreasonable for a compiler to error out if it sees this code, and ince we were working on an aggressive pointer analysis for C, we did do so. Of course, since the compiler failed on this code, autoconf concluded that the system didn't have memcpy, and it helpfully provided its own implementation... which immediately crashes the build (after autoconf completes, of course) for multiple redefinitions of memcpy.

To top it all off, it appears that there has never been any system that didn't have memcpy that was capable of running any version of autoconf, let alone any software written this millennium. This check literally has no benefit, and is "complex code [added] for no reason."

I don't understand why is it illegal C? memcpy is just another function in some library. It might be libc or not. I don't expect compiler to care about it, just put function call into object code and move on.

Warning might be useful.

Because it is a function in the C Standard Library. Programs are typically prohibited from declaring these functions. You can if you don't link with libc and pass in the correct compiler flags (gcc will turn some raw loops into a memcpy call as an optimization even without linking libc afaik)

https://www.gnu.org/software/libc/manual/html_node/Reserved-...

Compilation units are required to declare all standard library functions they call. They usually do so by including the compiler's header files rather than doing more work and risk errors with explicit declarations.

It's undefined behavior to call functions with a different set of arguments from its definition. The definition of memcpy is memcpy(void * , void * , size_t), and calling it with no arguments is obviously incompatible with the three required arguments here.

> I don't expect compiler to care about it, just put function call into object code and move on.

memcpy actually has a few semantics that cannot be legally expressed in C (specifically, strict aliasing doesn't kick in). All modern compilers actually define memcpy as a compiler-builtin, and they rely on memcpy's semantics for optimization purposes.

Or, put more bluntly, memcpy does not correspond to a function call in object code. C is not a thin wrapper around assembly code, and has not been so for quite some time.

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.

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

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

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

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.

> memcpy actually has a few semantics that cannot be legally expressed in C (specifically, strict aliasing doesn't kick in).

Are you sure? I hear this a lot, but I don't think it's really true. char pointers are allowed to alias pointers to any other type in standard C (C17 6.5p7,) so unless I'm missing something, a correct C implementation of memcpy could just cast both its arguments to char pointers and copy them char-by-char.

I agree with your premise that the call to memcpy() is undefined, but I think that's entirely because of the conflicting definition, and has nothing to do with any special semantics of memcpy, so it would equally apply to any other standard library function.

> Are you sure? I hear this a lot, but I don't think it's really true. char pointers are allowed to alias pointers to any other type in standard C (C17 6.5p7,) so unless I'm missing something, a correct C implementation of memcpy could just cast both its arguments to char pointers and copy them char-by-char.

I'm not completely certain. I have definitely seen this assertion before made by people more well-versed in the C standard than I, but I don't recall the exact argument. I think it may be the case that the write-via-char causes the effective type of memory to change (so it can only be read by char from that point on), but again, I don't trust my judgement here.

I think it might be an out-of-date assertion, but I'm not sure either since I also hear it from people who seem to be well-versed in the C standard. The only place in C17 where I can see memcpy singled out (6.5p6) also mentions copying "as an array of character type." The definition of memcpy itself just describes it as copying characters. It's true that some types can have bit patterns that are "trap representations," that is, they cause undefined behaviour when used, but memcpy can also create trap representations. You could memcpy to copy the bit pattern of a signalling NaN from an int into a float, for example.

memmove on the other hand can't be implemented in standard C, but it can be implemented on most platforms using only implementation-defined behaviour, because casting a pointer to an intptr_t is implementation-defined, but on most platforms with a flat memory model, it gives you the linear memory address.

> memcpy is just another function in some library. It might be libc or not. I don't expect compiler to care about it, just put function call into object code and move on.

The compiler has special knowledge of memcpy and may introduce calls to it even if you don't call it anywhere in your code - see this : https://gcc.godbolt.org/z/_w78qd

Hence standard library function names are "reserved for use as identifiers with external linkage", ie unless your implementation is 'freestanding', you're not allowed to re-define them.

The code above does not do so.

Contrary to what other people have suggested, according to my understanding of the C language standard, the word `memcpy` is not magical in any way, and undefined behaviour only comes in because the code will call `memcpy` with incorrect signature.

Another reason this asinine: Which platform has a C compiler but doesn't have memcpy()?!

I guess this is not an argument that the above code to check for memcpy() is illegal, per se, but it's at the very least totally superfluous.

The problem is, autoconf does a terrible job of supporting Windows, and actively rejects patches which would improve things (for example, it does very badly with spaces in filenames, which are common in Windows, for example "Program Files" and "My Documents")

Even Bazel doesn't support spaces in file names!

"My Documents" are called "Documents". You can also install your application into user directory, something like "C:\Users\Vladimir\AppData\Local\YourApplication", so no spaces necessary unless user name contains spaces (not sure if it's even possible).

I'm not claiming that spaces should not be supported, but you can live without them.

It's shame that it still needs workaround in 2020.

autoconf is an attempt to commoditize the insanity that people have experienced over the years. This is the wrong approach. The right approach is to make it easier to add checks for only your particular insanity. CMake does it correctly.

Not that I think autotools are great, but, to the contrary, feature-detection is exactly what all those macros in configure.ac etc. do, as opposed to cmake which tries to guess a platform and is a monolith with magical behaviour that nobody groks in its entirety. cmake, for one, is actually a case of the cure being worse than the illness. Already autotools treats Makefiles as output (and many macros shit gmake-specific if/else cascades into it) when the solution is simply using Makefiles properly, and assume POSIX headers/defs in this millenium. See git's Makefile, or those on suckless.org, for how to do it properly.

CMake doesn't do any feature detection if you don't want it to.

True but I think addressing those inconsistencies in the build system is doing it on the wrong level. Ideally this should happen outside the actual build and any dynamic configuration that is derived from the system environment should simply be passed into the build. CMake makes this easy using toolchains.

Is this really easy? I spent days lately trying to compile popular library on Mac for all platforms (Win, Linux) only to figure out that it is MUCH easier just to set up bunch of dockers/VM and compile it there. I suspect it is close to impossible to compile the library (LevelDB) for Linux on a Mac.

cross-compiling was necessary when hardware was expensive.

You can rent a Linux box for $10 if you want to compile.

To be clear, I'm not defending autotools.

But every C build system will have to deal with some mess. That may be having multiple configurations for multiple OSes (with weird exceptions for weird OSes or WASM), snowflake libraries that just had to have their own pkg-config replacement, fiddling with flags for various flavors and versions of MSVC and non-MSVC compilers, rpaths, sovers, etc.

To me it's inevitable that every project that starts with "just 5 lines of simple CMake/Makefile, look how simple it is!" will end up with the same mess everyone else ends up with.

Reply on news.ycombinator.com