Quantcast

Autoconf should fail if there are macros with invalid names

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Autoconf should fail if there are macros with invalid names

Demi Marie Obenour
While it is possible to avoid unexpected macro invocations by
overquoting all text that could possibly be part of a macro, neither
Autoconf itself nor most user code does this.  Unexpected macro
expansion would likely cause problems that would be difficult to debug.
 Therefore, Autoconf should fail if a macro has a name that is likely
to clash with user code.

I propose that all macro names that could possibly be expanded directly
(as opposed to only being expanded indirectly via indir or defn), and
which are not builtins like dnl, be whitelisted against the regex 
/_?(m4[A-Za-z0-9_]*|[A-Z]+_[A-Z]+)/ – that is, they must either be
within the namespace reserved by m4sugar, or they must consist only of
capital letters and underscores, may only have at most one leading
underscore, and must have at least one interior underscore.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Autoconf should fail if there are macros with invalid names

Eric Blake-3
On 02/21/2017 02:04 PM, Demi Marie Obenour wrote:
> While it is possible to avoid unexpected macro invocations by
> overquoting all text that could possibly be part of a macro, neither
> Autoconf itself nor most user code does this.  Unexpected macro
> expansion would likely cause problems that would be difficult to debug.
>  Therefore, Autoconf should fail if a macro has a name that is likely
> to clash with user code.

There's already m4_pattern_forbid for flagging names that are likely to
be macros but which were not expanded; but it sounds like you are asking
for the opposite of flagging any m4_define() of a macro name that does
NOT look like a normal macro name.

>
> I propose that all macro names that could possibly be expanded directly
> (as opposed to only being expanded indirectly via indir or defn), and
> which are not builtins like dnl, be whitelisted against the regex
> /_?(m4[A-Za-z0-9_]*|[A-Z]+_[A-Z]+)/ – that is, they must either be
> within the namespace reserved by m4sugar, or they must consist only of
> capital letters and underscores, may only have at most one leading
> underscore, and must have at least one interior underscore.

I suppose the implementation of this would be done by hooking
m4_define() and friends so that it is impossible to define a macro
unless it matches the whitelist or your regex of macro-looking names.

I'm afraid that in general, this is highly prone to break existing
setups (it's always harder to add tighter rules after the fact than it
is to start with tight rules and relax them).  But you're welcome to try
your hand at a patch.

Maybe even just making it a warning is sufficient?  For example, if I do
m4_define([bad], [...]) or AC_DEFUN([bad], [...]) or any other
high-level macro, then issue a warning that 'bad' is a suspicious macro
name, but still proceed to generate the output as has always been done
in order to avoid breaking scripts in the wild?

And as for your proposed regex, it's too tight - I'm aware of projects
in the wild that use lower-case for the namespace portion of their macro
names; for example, gnulib has [gl_INIT].  So requiring all uppercase is
a bit too strict; but requiring an underscore (so that there is a
separation of namespace and rest of the name) may make sense.  Likewise,
requiring no digits is too harsh; for example, gnulib has [gl_FUNC_ATAN2].

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


signature.asc (617 bytes) Download Attachment
Loading...