Oh, that subject line is *so* overselling this...
On Sat, 2011 Oct 15 02:08+0200, Bruno Haible wrote:
>
> Thanks for these two. I committed them in your name:
Much obliged!
> In git log, your committer name comes out as
> "Daniel Richard G <sk...@iskunk.org>"
> aithough I used the option --author="Daniel Richard G.
> <sk...@iskunk.org>".
>
> I don't know how to make 'git' preserve the trailing period.
Close enough :) Though I probably have good standing to file a bug
against Git on that...
> > * "checking whether perror matches strerror": strerror(-1) returns
> > an invalid pointer, and attempting to puts() this yields SIGBUS.
> > (Wouldn't it be safer to pass EPERM or something similarly
> > universal?)
>
> This is the purpose of the test: testing whether you can safely pass
> invalid error number, such as -1, to strerror.
I thought it was to test that perror() and strerror() gave the
same output.
Note that currently, the test passes despite the SIGBUS. It should
probably check that $? = 0 before comparing stdout vs. stderr.
> All C and C++ compilers newer than SunOS 4 cc support any amount of
> spaces before and after the '#' in preprocessor directives. We are
> taking advantage of this fact, indenting the entire programs in files
> such as perror.m4. We don't care about the amount of whitespace that
> gets added to the generated 'configure' file.
IIRC, the vendor C compiler on circa-1997 Tru64 had this limitation, in
its default language-compliance mode. (I'd double-check this, but my
employer's system has been offline for some time with a bad disk.)
> This is an easy fruit: I used the condition
> # if defined __GNUC__
> in stdio.in.h. It could be refined if we know the first GCC version
> which supports this 'asm' syntax.
Sigh... "Asm Labels" are documented in extend.texi in the source
distribution for gcc-2.5.8. What on earth did NeXT do to this poor
compiler??
(You could always tack on '&& !defined __NeXT__'...)
> Is this GCC version defining __STRICT_ANSI__ to empty, or is it unable
> to evaluate unknown identifiers to 0 in preprocessor expressions? In
> the first case, you could add -D__STRICT_ANSI__=0 to your CPPFLAGS.
Apparently, the system headers are defining it to empty (seems to be a
side effect of -D_POSIX_SOURCE), and GCC cannot evaluate unknowns to 0.
Testing this experimentally...
#define FOO
#if FOO == 0 /* fails */
#if FOO >= 0 /* fails */
#if (FOO + 0) >= 0 /* succeeds */
#if (0 + FOO) >= 0 /* fails */
#if !FOO /* fails */
-D__STRICT_ANSI__=0 is no good, because this symbol is checked via
#ifdef / #if defined() in the system headers.
(Which, I'm thinking, is probably what gnulib should be doing too,
rather than the +0 hack.)
> But in the second case, all hope is lost, because we do
> #if !HAVE_FOOBAR
> in hundreds of places.
Well, if HAVE_FOOBAR is supposed to be 0 or 1, then that's fine. I
didn't run into any (other) problems with conditionals like this---and
this system has a lot fewer HAVE_* than most.
> > (Setting LIBS=-lposix isn't an option, alas, as this produces
> > broken binaries that fail instantly with "Floating point
> > exception")
>
> Oh shit...
Probably another VM-related quirk. It's not like -lposix wasn't heavily
used back in the day (and this is a fully-patched system).
> Good. But I didn't see the sleep/alarm workaround in your gnulib-
> fixes.patch?
Right now, that test uses an absurdly long sleep() period (50 days), so
if the alarm() call fails, you're not going to wait for a timeout.
Would the test still be effective if the period were taken down to
ten/fifteen seconds?
> Thanks for the offer, but it would not be a worthy use of your
> time :-)
One of these days, I'll have to play around with 4.2 BSD...
I promise I won't submit patches for that one ^_^
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
