Re: ld-output-def

[Simon Josefsson]

Eric Blake <address@hidden> writes:

> According to Simon Josefsson on 4/1/2009 8:14 AM:
>> Thanks.  Is there some way to systematically find these?  A m4 code
>> validator or similar?
>
> Unfortunately, not that I know of.  So the best we can do is repeatedly
> remind people to follow the autoconf rule of thumb: always provide one
> layer of quoting around each argument to a macro, even when omitting the
> quoting won't change the output, so that you establish a good habit and
> don't get surprised by the cases where omitting the quoting causes early
> macro expansion and knock-on problems.

A script to manually verify this would be useful to reduce the amount of
people time.  I'm sure I've made this mistake in the past, and will thus
likely do it again... :(

>> I don't understand this part, what possible bogus entry could the user
>> supply that would cause
>> 
>>   AM_CONDITIONAL([HAVE_LD_OUTPUT_DEF], test "$gl_cv_ld_output_def" = "yes")
>> 
>> to fail?
>
> gl_cv_ld_output_def=\( ./configure
>
> Even though Posix says this should silently return non-zero exit status,
> some test implementations complain to stderr if the argument starts with
> something that looks like an operator or option.  Hence, any time you are
> validating the contents of a variable that can be set outside of your
> control, you should always prefix it with x, to ensure that it doesn't
> start with -, (, ), etc.

"test implementations"?  If there aren't any more widely deployed
implementations out there that break (like irix, hpux or some other
system that we do support), IMO it makes the code harder to read for no
good reason and that we are better off making people stop use these test
implementations.

But I don't care strongly, so I adopted your suggestion.

/Simon