Order of operations

Carnildo

Just a snippet from the output of a Linux "configure" script:

checking sys/file.h usability... yes
checking sys/file.h presence... yes

The order of operations here implies that it's possible for a header file to be usable but not present.

H_B

Reminds me of the many if (something.Test() && something != null) I see once in a while...

jcoehoorn

@H|B said:

Reminds me of the many if (something.Test() && something != null) I see once in a while...

That reminds me of an old VB6 WTF:

In the debug environment, function arguments where evaluated right to left. In the release environment, they are evaluated left to right. Or vice versa, I'm not sure which anymore. The issue was mitigated somewhat since VB didn't do short-circuit evaluation, but it was still possible to get erroneous results if you had something like this:

If FunctionThatCanThrowError() And FunctionThatUpdatesDatabase() Then

End If

MarcB

@Carnildo said:

Just a snippet from the output of a Linux "configure" script:
checking sys/file.h usability... yes
checking sys/file.h presence... yes
The order of operations here implies that it's possible for a header file to be usable but not present.

My guess would be that parts of the config script call various tests recursively, and outputs the results at the bottom of the call after any sub-results of the test are completed.

asuffield

@Carnildo said:

The order of operations here implies that it's possible for a header file to be usable but not present.

It is. This is a compatibility macro and the progress messages are somewhat unclear.

A header is usable if the compiler will accept it. A header is present if the preprocessor, running alone, will accept it. These two things may not agree on all systems, particularly if you are not using gcc.

Historically, autoconf checked only the preprocessor. Future versions will check only the compiler. Currently it's in transition so it checks both. The order of operations is actually not significant, since both tests are always run regardless of the results, and current versions consider the header valid if either the compiler or preprocessor will accept it.

asuffield

@MarcB said:

My guess would be that parts of the config script call various tests recursively, and outputs the results at the bottom of the call after any sub-results of the test are completed.

No, that's the sequence in the code.