I don't really understand what in this feature makes the build non-reproducible. Judging by the patch it's the call to time(NULL) that seems to be problematic, but I don't understand why.
The output of "apt-get moo" changes on special days (4/1, 12/25, 8/16, 11/7, 2/18). So if another program was using "apt-get moo" in its build script, the build would not be reproducible. With the patch, the SOURCE_DATE_EPOCH environment variable can be set to make "apt-get moo" deterministic.
I don't think anything actually uses "apt-get moo" in its build script.
This kind of patch makes more sense for build tools like "ar" (static library creator). By default, "ar" injects a timestamp into the output file, so the binary is different each build. But, use the "D" flag and "ar" becomes deterministic.
Yeh I only skimmed the patch but I presumed "reproducable build" referred to the actual binary, and the patch addresses runtime behaviour. Guess I'm missing something.
Sure, but you know what does make this idea better?
The fact that it's pretty much the most sane way to consistently handle errors in a complicated C program. In particular if you have multiple paths out of your function and it also makes memory allocations, that's an overcomplicated amount of free() calls you need to take care of, remember are there, and maintain as you add/remove allocations and failure paths. goto lets you keep it simple by only maintaining a single block of free()s at your function's single exit path.
Granted it seems this file is C++ and therefore the "going full RAII" option exists and could avoid goto in favor of exceptions or early returns... But if your code is C style that is a tough conversion to make, and not everybody buys into it equally.
True, insightful, but completely beside the point - which was "bracketless conditionals open up an avenue for coding errors."
The fail in #gotofail wasn't in using GOTO - it was a coding error, where a misindented line after a bracketless condition was always executed, when it should have been only executed inside the condition.
When it shows up in the kernel it is likely to be deep in a hairy if cluster inside some driver code. Thus if you get a failure of some sort it is quite likely that it is best to just drop everything and get out, as the whole edifice is about to come down anyways.
^^^ that part is written in a misleading way and doesn't do what it seems to do on first glance.
It is unfortunate that the problematic line contained a jump, because "#gotofail" seems to convey "GOTO considered harmful", while it's something completely unrelated. Ironic, really, given the actual meaning of "human looks at a block of text and misparses it."
You're conveniently not mentioning that this would cause very similar issues:
if (some_cond) {
goto fail;
}
goto fail;
if (some_cond) {
goto fail;
}
if (some_cond) {
goto fail;
}
if (some_cond) {
goto fail;
}
Is it more obvious? Sure. But the real issue is that they weren't testing all of the important failure cases, not that they weren't using one code style over another. Coding style is not going to help you if one of those some_cond values is incorrectly written...
"More obvious" is precisely my point: the misindentation in your example jumps out at anyone familiar with the syntax. This is not an universal cure, and won't help you with other types of semantic errors: nothing is going to help you if you try to avoid thinking and rely solely on your tools; that is the essence of cargo-cult programming.
OTOH, this tool will help you avoid a common pitfall with potentially disastrous consequences. A high-visibility vest for coding, if you will: won't save you from slipping or your head from falling objects, but neither is its purpose.
(Iterative bootstrapping is how we got from sharpened rocks to virtual machines, not by "meh, this minor improvement won't fix everything, so why bother.")
May or may not. Given that popularity breeds more popularity, all it actually says is that it was popular enough, sometime in the past, to start a runaway process (I don't really want to start a flame war of "look at those popular yet fairly horrible things/languages/whatevers")
I agree, but to be fair, goto fail was not really caused by the lack of curly braces around an if statement body. It was caused by inadequate code review and lack of testing coverage. The latter especially is inexcusable in security-critical code.
That logic clearly fails, though. You will never do everything to prevent a failure. (As an example, there are almost always stronger materials. Cost is a requirement,)
Though, your point here is interesting. Using curlies probably could have stopped that bug. Using static analysis that saw dead code definitely would have stopped it.
In this case, mechanisms (automatic checking for dead code) are vastly superior to good intentions (always using curlies).
I didn't mean literally everything. I mean everything that has more benefits than costs. I consider consistent curly brace style to fit in that category.
Out of millions of CVEs, one is plausibly related to this coding style. I don't think that's a strong argument for using the more verbose style. If we saw this all the time it might be a different matter.
I think it is a strong argument for compilers' -Wall to detect misindented statements directly following unbracketed conditional expressions, though.
Because one takes an extra line. For something that's effectively an error condition. There's so reason errors should take up so much vertical code space (which is at a premium even today, given how wide monitors are). This is one of my primary quibbles with golang, and why I will never give in to the community's slavish devotion to "go fmt @
Yikes. Do you realize how useful it is to have a single consistent formatting for source code? It eliminates an entire class of arguments. Or do you enjoy arguing about tabs and spaces, and when to make newlines?
No doubt it's quite weird, but I am of the opinion that hardware should serve the code and coder, not the other way around. Maybe use a portrait orientation tablet with a bt keyboard for travel. I think there could be a small market for laptops with a portrait mode, too.
