bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mark atexit, memchr, memcmp, memcpy, memmove, memset, raise, rmdir,


From: Bruno Haible
Subject: Re: mark atexit, memchr, memcmp, memcpy, memmove, memset, raise, rmdir, strcspn, strpbrk as obsolete
Date: Tue, 21 Oct 2008 00:45:55 +0200
User-agent: KMail/1.5.4

Jim Meyering wrote:
> Since you listed Irix 6.2 and AIX 4.3.2 as being immune, I presumed
> that versions earlier than those, yet with the same major number,
> may be impacted.

Not necessarily. Simply, we don't have data about IRIX 6.1 and AIX 4.2.

> If, as you now imply, all of 6.x and 4.x.x are
> not affected by the removal of those modules, then it may be
> less of a problem.  The trouble is that it's hard to _know_.
> What if there are other systems?

We know pretty well. For 5 years, I've built up the database of function
availability which we now have in the doc/*/*.texi files. Systems that
are not in this list are systems which were active before 1997.

> My concern is that package maintainers will address the warning
> (remove those modules) without realizing that for minimal benefit they
> are removing pieces that may make their project less portable to fringe
> systems.

It's not just "fringe systems". (I would use this term for OSF/1 4.0,
HP-UX 11.00, Solaris 7, and the like.) It's the systems which did not
ship with an ANSI C compiler. The systems where you cannot compile
libiconv with -g because you either hit bugs in the assembler or otherwise
fill up /tmp.

> Not just old ones, but perhaps embedded ones, too, and they
> would be unlikely to notice the regression right away.

uClibc at least has all sorts of configuration options which allows the
developer to include or exclude various functionalities.

> A more conservative approach would be to make each of those
> proposed-obsolete module AC_REQUIRE a new macro with code to run at
> configure-time if ever the module is required.  That code could make
> configure fail by default with a diagnostic

This approach would be good if we did not know about the possible portability
problems. But our database in doc/* tells us.

The functions we are talking about were apparently all part of ANSI C, and
added by vendors in the years 1992-1994, in the scope of ANSI C compliance.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]