[hf]

The answer seems to me quite simple: because they have a different coding style. Just as no one is bound to K&R or the GNU style, nothing suggests that crypto code needs to follow Linux kernel conventions.

Value consistency above everything.

Honestly, I am not convinced that the peculiar if-style isn't actually helping readability and refactoring. Note, that a Apple-style "goto break" bug might be harder to construct, when your one-line if's look like this:

   some_code;
   if (something) die(message);
   other_code;

Now the surrounding indentation does not suggest that there's an extendable block where there in fact isn't, as with Kernel style:

   some_code;
   if (something)
       die(message);
   other_code;

To be perfectly honest, the authors' style reminds me a bit of my younger self's style: keep logically connected pieces of code tightly together.

You (presumably) and I have beaten ourselves into submission to the Linux style; the authors' haven't.

On a side note: your second example even seems to suggest that the authors made some effort at additional readability by refraining from using the ternary operator construct.

[yp_all]

"You (presumably) and I have beaten ourselves into submission to the Linux style; the authors' haven't."

An awakening!

Is it really so terrible to have things compile quickly and without the usual ./configure nonsense? It seems there are an infinite number of ways an author can organise her project using ./configure; for every one I have to spend time figuring out what they have done.

One of my favourite aspects of djb's build approach (which is what is being used here) is that it's easier (than with the popular build systems) to change compiler and linker options and make static binaries: in most cases, simple edit the conf-* files. Thankfully, authors who use djb's approach usually do not vary much from the model. This means less time spent figuring out how things are organised.

I like (portable) open source software that compiles quickly and cleanly.

djb has continued to deliver on this point.

Nice to see someone discovering this build system for the first time.

[lmz]

I'm just curious, where does the parent post mention anything about the build system? The "Linux style" referred to there seems to be the Linux code style, not "configure".

[dima55]

On top of that "configure" has nothing to do with Linux.

[yp_all]

Who said it did? Consider that I was commenting in a general sense.

djb's work, whether it's coding style or build system or something else, tends to differ from what is "popular".

The parent's comment is along the lines of: what is unfamiliar can appear more difficult, but after the adjustment it may actually appear easier than the prior alternative.

If you view the parent's comment in this light, then you will see that both the Linux kernel coding style and the GNU build system are very familiar for lots of folks.

If you are migrating to using tinyssh and other software that follow's djb's style for the first time, then you will no doubt have to "get used to it" and you might even perceive it as being difficult.

To be crystal clear, I'm not singling out the Linux kernel or the GNU build system. The GNU build system is but one example; the Linux kernel coding style is another.

I could make a lengthy list of "familiar", popular approaches that I could argue are inferior to djb's approach to the same task.

It's just my opinion. If you disagree, feel free to state your own opinion.