Re: The machine stack and the C language

roberson@xxxxxxxxxxxxxxxxxx (Walter Roberson) writes:
In article <87fxwhdop8.fsf@xxxxxxxxxxxxxxx>,
Keith Thompson <kst-u@xxxxxxx> wrote:
But the only reason to
execute "/bin/true --version" with the expectation of having it do
nothing is deliberate conformance testing. There's no real-world
reason to give it an argument at all.

Real life example:

Portable(-ish) Makefiles with a step that would normally be
ar -t (topological sort on the archive contents) but that step
is unneeded or unimplemented on some architectures. The usual
solution is to parameterize the program name as a variable in
the makefile, and for those architectures that do not need or
support the step, use /bin/true or ':' (colon) as the program name,
taking advantage of the fact that arguments will be ignored but
the step will be considered to succeed.

It's even conceivable that the Makefile might want to invoke
"ar --version", so information about the tools used is recorded in the
output log (if the Makefile assumes that ar accepts the "--version"
option). Invoking "true --version" instead isn't likely to kill
anything, but it could cause some confusion.

If you assume an error "can't happen", stop a moment and consider that
computers are capable of making mistakes that would never occur to a
human, and of making them at an incredible rate. Think about this
before deciding that using an identifier with a leading underscore, or
adding a non-standard declaration to a standard header, or ignoring
the possibility that malloc() could fail, can't possibly cause any
problems in the Real World. The C standard doesn't mention Murphy's
Law, but it still applies.

<EVEN_FURTHER_OT>
More recent versions of the GNU "true" command apparently ignore
POSIXLY_CORRECT.
</EVEN_FURTHER_OT>

--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.