It's part of a test program used for feature detection (of a sandboxing functionality), and causes a syntax error. That in turn causes the test program to fail to compile, which makes the configure script assume that the sandboxing function is unavailable, and disables support for it.

You are looking at a makefile, not C. The C code is in a string that is being passed to a function called `check_c_source_compiles()`, and this dot makes that code not compile when it should have -- which sets a boolean incorrectly, which presumably makes the build do something it should not do.

Interesting that validating the failure reason of an autotools compile check could be a security mitigation...

This is something that should have unit/integration tests inside the tooling itself, yeah. If your assertion is that X function is called / in the environment X then the function should return Y then that should be a test especially when it’s load-bearing for security.

And tooling is no exception either. You should have tests that your tooling does the things it says on the tin and that things happen when flags are set and things don’t happen when they’re not set, and that the tooling sets the flags in the way you expect.

These aren’t even controversial statements in the JVM world etc. Just C tooling is largely still living in the 70s apart from abortive attempts to build the jenga tower even taller like autotools/autoconf/cmake/etc (incomprehensible, may god have mercy on your build). At least hand written make files are comprehensible tbh.

It's a "does this compile on this platform" test, not a "does this function return what we expect" test.

Unfortunately in the world of autoconf and multiple platforms and compilers, there was no standard way to understand why the compilation failed.

Cmake actually but yes

As far as I can tell, the check is to see if a certain program compiles, and if so, disable something. The dot makes it so that it always fails to compile and thus always disables that something.

> if a certain program compiles, and if so, disable something.

Tiny correction: [...] enable something.

The idea is: If that certain program does not compile it is because something is not available on the system and therefore needs to be disabled.

That dot undermines that logic. The program fails because of a syntax error caused by the dot and not because something is missing.

It is easy to overlook because that dot is tiny and there are many such tests.

I had a similar problem with unit testing of a library. Expected failures need to be tested as well. As an example imagine writing a matrix inversion library. Then you need to verify that you get something like a division by zero error if you invert the zero matrix. You write a unit test for that and by mistake you insert a syntax error. Then you run the unit test and it fails as expected but not in the correct way.

It's subtle. It fails as expected but it fails because of unexpected wrong causes.

The solution: Check the errors carefully!

> The solution: Check the errors carefully!

The desire for "does this compile on this platform" checks comes from an era where there was pretty much no way to check the error. Somebody runs it on HP-UX with the "HP-UX Ansi C Compiler" they licensed from HP and the error it spits out isn't going to look like anything you recognize.