Re: porting to NeXTstep

[Daniel Richard G.]

Sorry for the delay; didn't have time to revisit this till today.

On Wed, 2011 Oct 19 11:23+0200, Bruno Haible wrote:
>
> The files m4/strcoll.m4, lib/strcoll.c, modules/strcoll,
>           m4/string_h.m4, lib/string.in.h, modules/string,
>           doc/posix-functions/strcoll.texi
> are probably the ones that need to be modified. We generally use the
> same idiom for replacing (= overriding) a system function. You find
> dozens of examples of this technique.

Question: In the case of the system providing a (presumably) usable but
nonstandard form of strcoll(), should gnulib cause calls to the standard
function to be redirected to the non-standard one (via macro or wrapper
function)? Or should it just replace the function with its own
implementation, ignoring the nonstandard form?

> > * New and improved absolute-header matching code.
>
> I rewrote that to handle all characters that might need to be escaped,
> not only '.' and '/' but also '^', '[', and others.

Good call. This is working perfectly.

> > * Make use of setrlimit() if available to escape from the infinite
> >   frexp() trap.
>
> Here I prefer to use alarm() instead of setrlimit(),
> 1. because it's easier to use,
> 2. because some platforms probably define RLIMIT_CPU but don't
>    implement it.

Ah, okay; I only used setrlimit() because "ulimit" was the first thing
that came to mind, and some other tests use setrlimit() in its other
capacities.

This is working too, which was a bit surprising, because I thought from
the sleep() test (erroneously, it now appears) that alarm() was broken
on this system. More on that in a bit.

> > * Many of the tests still fail to build, not because the functions
> >   for them are not available, but because said declarations for
> >   these functions either disappear with -posix->_POSIX_SOURCE->
> >   __STRICT_ANSI__ (which we can't do anything about), or don't
> >   exist in any standard headers at all.
>
> This needs to be worked around on a case-by-case basis. But out of
> laziness, I would not do anything for functions that return 'int'
> (because 'int' is the default return type that the compiler assumes
> for functions without a declaration).

The signature check causes the breakage, however. I'm not sure if these
are worth the effort, but I'll see what's left once the other bits are
addressed.


On Sat, 2011 Oct 22 14:27+0200, Bruno Haible wrote:
>
> OK. Daniel provided a patch [to m4/perror.m4], but I find it
> stylistically better to use 'if', '&&' or '||' than 'test $?'. I'm
> committing this:

I'm in agreement here; it's concise, and it sidesteps entirely the
question I had at the back of my mind when writing the patch (why does
gnulib not like test(1)'s -eq operator?).


On Sat, 2011 Oct 22 14:41+0200, Bruno Haible wrote:
>
> > * Tacked on "&& !defined __NeXT__" in lib/stdio.in.h. Easier than
> >   adding a separate test for asm-label functionality, anyway.
>
> I don't remember: What is the version of NeXT gcc? Does it support the
> __attribute__ __format__ __printf__ syntax?

    $ cc -v
    Reading specs from /lib/i386/specs
    NeXT Computer, Inc. version cc-437.2.6, gcc version 2.5.8

Stock 2.5.8 supports asm labels per the documentation, so for whatever
reason, NeXT took that out. Giving -U__GNUC__ might even be sort-of
semantically correct in light of that, but I haven't run into any other
troublesome GCC constructs that gnulib hasn't already conditionalized.

Would an explicit test for __asm__ label support be preferable?

>   extern int printf (const char *format, ...)
>     __attribute__ ((__format__ (__printf__, 1, 2)));

If I try compiling code with this construct, I get

    warning: `__format__' attribute directive ignored

???

> > * I missed that the 50-day sleep is necessary to check for a Cygwin
> >   bug. So I tweaked the test so that this long sleep is only used on
> >   Cygwin (where, presumably, alarm() has always worked correctly),
> >   and all other systems use 15 seconds.
>
> This patch looked clumsy, sorry. What is the original problem? That
> alarm(1) does not work? What can be done to make it work?

Okay, the comment I put in there is wrong. After seeing your frexp()
code work as intended, I copied out the sleep() test-program code, and
did a little more investigation on this.

When you build with "cc -posix", sleep() and alarm() work exactly as
POSIX says they should. No problem there.

When you build without -posix, sleep() does not exit early on SIGALRM.
The signal handler is called, but then sleep() keeps going for the
remaining amount of time.

I think the code change in the patch is still good (use the 50-day delay
only on Cygwin where it's relevant, a much shorter delay everywhere
else), but the explanation in the comment needs revising.

> > * I've added a definition of EILSEQ to lib/errno.in.h; does that
> >   look right?
> >
> >   The libiconv folks may need to be pinged about this change, as I
> >   noticed that they check for EILSEQ too, and if it's missing,
> >   #define it to ENOENT.
>
> Good point. And adding EILSEQ in errno.in.h also requires a change to
> lib/strerror-override.c.

The patch may be minor, but it's attached.

> Have you been progressing recently? If so, I'll turn to this EILSEQ
> issue next.

I've been poking at the strcoll() issue, trying to figure out how to
fit that in.


--Daniel


-- 
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.

gnulib-eilseq.patch
Description: Text Data