Re: more efficient AS_EXIT

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 10/25/2008 3:36 AM:
> Hi Eric,
> 
> * Eric Blake wrote on Thu, Oct 23, 2008 at 10:04:56PM CEST:
>> So, based on the recent discussion, does this patch look sane?  I also tried 
>> to 
>> clean up _AS_PREPARE, so that it doesn't require a duplicate listing of 
>> as_func_mkdir_p just to work around AS_REQUIRE* issues.
> 
> Hmm, this patch seems to squash in a couple of changes that could be
> done independently.

I'll try to split it, then, and provide the _AS_REQUIRE_SHELL_FN
factorization first (it is useful in its own right, whether or not we
change AS_EXIT).

> 
> For bonus points, is it possible to defun AS_EXIT as plain exit for as
> long as the trap isn't in place, or as '(exit X); exit X' for as long
> as we are before any shell function, and the redefun it as the cool
> version at that point?  That way you could keep using AS_EXIT
> everywhere, consistently.

How would m4sh know whether it is in a trap context?  The user would be
required to call the as-yet-unwritten AS_TRAP to set up all trap contexts
for this to work (ie. any existing m4sh code that uses m4sh writes their
own trap code without informing m4 that context has changed).  Not to
mention the issue with diversions (just because a trap is active in the
main body does not mean the trap is still active if you AS_REQUIRE
additional text into an earlier diversion).  So I think it is safer to
always assume we are in trap context.  The amount of code prior to
functions being defined is well-defined; but maybe there, I could use
m4_pushdef([AS_EXIT],[exit $1])/m4_popdef([AS_EXIT]) inside those few
macros (_AS_SANITIZE, ...), so that we never see raw exit in autoconf's
source base outside of the AS_EXIT macro.

> 
> I wouldn't bother much about performance here BTW, it's not like it's
> common to execute many AS_EXITs during one script run.  :-)
> (And it's not much of a text reduction either.)

You're right - on coreutils, I think the size of configure even increased,
because even though there were fewer bytes in all the AS_EXIT sites, the
prep in AS_PREPARE and _AS_PREPARE was bigger than the savings.  It could
be more of a reduction, if we were willing to shorten the function names
to as_exit (I'm okay with exceptions to the rule of thumb about the
as_func_* namespace, as long as we have a good reason for it and aren't
worried about inadvertant namespace clashes - for that matter, since we
own the entire as_* namespace and the user should always be going through
our macros unless we document a variable name, maybe we can get away with
shortening all of our macro names).

> 
> FWIW, I didn't try your patch because it seemed to be mangled on the

It's currently floating on my branch of questionable patches:
http://repo.or.cz/w/autoconf/ericb.git?a=shortlog;h=refs/heads/exit

> way, but it looks like the function you're using to exit does not avoid
> the zsh exit status in function bug.  (Yes, I know the shell is supposed
> to be rejected, but if poor sap has no other one?)

The zsh problem is already an issue for other reasons (_AC_*_IFELSE); the
next autoconf release will be beta, and hopefully we will hear a report
from anyone running a configure script while stuck on such a broken
system.  But Paolo is correct, the zsh bug affected subshells, not return
statements, so this implementation does not aggravate the zsh bug.  (Hmm.
 I should download and build my own zsh 4.3.2, where the bug was still
present; cygwin now ships with 4.3.4 where it is fixed).

> 
> So all in all I'm kind of wondering if this patch is worth the hassles
> it introduces.

I'll keep the patch updated, but we'll re-evaluate it after applying the
non-controversial improvements.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkDDNUACgkQ84KuGfSFAYBmiACgicibimoBoDZA5QaMXzitLmaQ
zc4An1/QoSGoCq50Wg7A5lAAsRxLxBoR
=91Lf
-----END PGP SIGNATURE-----