Re: porting to NeXTstep

[Daniel Richard G.]

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 <address@hidden>"
> aithough I used the option --author="Daniel Richard G.
> <address@hidden>".
>
> 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. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.