Re: extensions module and Solaris

[Eric Blake]

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

[adding m4-discuss]

According to Bruno Haible on 5/27/2008 4:43 PM:
| Hi Eric,
|
| It seems that your problem is that you want execute a script via system()
| and at the same time force a particular shell, namely the $CONFIG_SHELL
found
| at configure time?

Something along those lines - POSIX doesn't require m4 to use system(2),
merely that it treat the argument to the syscmd macro as a shell command.
~ But if you want a POSIX-compliant m4 on Solaris, then syscmd must not use
/bin/sh, since /bin/sh doesn't obey the POSIX rules of parsing shell
commands.  Using $CONFIG_SHELL from configure-time is likely to be a POSIX
shell, but your luck is even better if we used the equivalent of finding
sh in 'command -p getconf _CS_PATH'.

|
|> $ gcc -o foo -Wall foo.c /usr/ccs/lib/values-xpg4.o
|
| I would not use this approach for three reasons:
|
| 1) When you have to use /usr/ccs/lib/values-xpg4.o to get a particular
|    behaviour, the chances are high that you will not be able to find a
|    solutions for some other systems.

As far as I can see, the problem is limited to Solaris, which is
specifically documented as having two different system(2) implementations,
based on what the compile-time environment requested.

| 2) Linking with /usr/ccs/lib/values-xpg4.o may be contradictory with
|    the CC options. If you set CC and CFLAGS so as to get traditional
|    behaviour and then link with a file to get XPG4 behaviour, I would
|    not bet that there aren't bad side-effects.

True.  I guess if a user is concerned about POSIX compliance on Solaris,
then they have control over the compiler and flags to ensure that.  It's a
bit of a shame that they can't get POSIX compliance without using
non-default flags, though.  Documentation in INSTALL might be valuable here.

|
|> Should we figure out a way to make inclusion of the extensions module
cause
|> compilation on Solaris to favor the standards-compliant behavior of
various
|> functions?  Should we try to directly add values-xpg4.o to the link
line, or
|> are we better off providing a .c file which provides the same
definition of
|> __xpg4 as what values-xpg4.o provides?
|
| 3) You are assuming a program being built. But gnulib is also used to build
|    libraries, such as libgettextpo or Simon's crypto libraries. What effect
|    would it have to put values-xpg4.o into such a shared library? It would
|    probably cause a change of behaviour to _all_ programs linked with such a
|    library.

Good points.  But all it can do is make the program more likely to be
POSIX compliant.  In other words, I'm not yet convinced that always using
xpg4 semantics is bad.

|
| Instead I would stop using the 'system' function (in particular its signal
| handling behaviour is more often undesired than desired) and use the
'execute'
| module instead. It allows you to specify the program to be launched
explicitly,
| without any hacks.

Does the execute module allow distinguishing exits due to signals from
regular exits?  M4 is currently documented as treating the sysval macro
differently to allow the user to distinguish between signals, but it looks
like wait_subprocess collapses all non-fatal signals into 127, which would
be a loss in functionality (and a difference from Solaris m4 behavior).
Also, m4 currently uses both system (for syscmd) and popen (for esyscmd);
it looks like the pipe module (specifically create_pipe_in) is the
counterpart for esyscmd (although it uses fd rather than FILE *, so it
would need some wrapping with fdopen before being used in m4).  Finally,
it looks like execute.c blindly undefines open, but this conflicts with
"fcntl--.h" from the fcntl-safer module.  Does the code properly make sure
that if fd 0, 1, and/or 2 were closed before creating the child process,
that the new fds created for communication with the child do not interfere
with the three automatic stdio streams?

- --
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

iEYEARECAAYFAkg80pYACgkQ84KuGfSFAYDLEwCgoq/svD6dPjYkX/N4cc9/gBxp
WaQAoKJdZOUdnQNnhst5rbPLtoVB7gBn
=GlUb
-----END PGP SIGNATURE-----