Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: