Artsize still not quite right in CURRENT

[Russ Allbery]

James Ralston <qralston+ml.inn-workers at andrew.cmu.edu> writes:

> You're correct, however; the build step will still bomb out.  The reason
> that happens is because parts of INN use BSD-isms (the u_short, u_int,
> et. al. typedefs),

Um, where?  Everywhere I saw stuff like that, INN was doing the typedefs
itself.  We *definitely* shouldn't be using anything of the sort unless
we're setting up our own typedefs for it.  (We probably just shouldn't be
using it at all; unsigned short is more typing, but it's clearer and more
portable.)

> There's a certain amount of irony here, I think: INN (as it currently
> stands) is an argument *for* feature-test macros.

Nope, you just made an *extremely* persuasive argument *against* feature
test macros; because glibc is using feature test macros, it's hiding a
latent bug caused by that namespace collision that sooner or later is
going to come bite us and make INN unbuildable.  If glibc hadn't done
that, we would have caught that problem right away.

This is *exactly* why I don't like feature test macros.  Sooner or later,
glibc will change what symbols are visible by default, and suddenly bugs
will show up unrelated to recent code changes.

(Patches for this problem are very much welcome.)

> I suspect this is why the glibc maintainers implemented the feature-test
> macros.

No, I know why they implemented the feature test macros; it's required by
the C, POSIX, and UNIX standards.  If it weren't, I'm pretty confident
that glibc *wouldn't* have feature test macros, since it was always RMS's
policy to make all extensions visible and available by default.

Feature test macros are one possible solution to the namespace problem.  I
can think of a few other possible solutions that I'd like better, but it's
definitely way too late now.

> As more functionality is added to the C library, and more symbols are
> defined, the chances of clashes with programs that were written before
> those symbols were defined increases.  If INN--which is under active
> maintenance and development--has symbol clashes with the complete
> functionality of glibc, what chance do the hundreds (if not thousands)
> of programs and packages which *aren't* being actively maintained have
> to avoid symbol clashes?  If every new symbol or piece of functionality
> added to glibc were automatically visible, the number of older programs
> that would clash with those symbols might be so great as to cause people
> to refuse to upgrade glibc.

The solution to this is to not make new symbols available in standard
headers, but instead when you add new functionality put it in a new
header.  That's the way that C implements namespaces, and it works quite
well.  Old programs don't include the new header and therefore don't get
the new symbols.  Unfortunately, one still has to deal with all the legacy
crap that people put into standard headers before the standards came out
(like fdopen in stdio.h), but at least that's a bounded set of stuff.

By and large, this *is* the way things are done, which is why we don't
have to worry about our hash_* functions conflicting with system functions
since no one's going to go and add hash_* functions to unistd.h.  They may
well add hash_* functions to their C library, but they'll be in hash.h or
some similar header that we're not including and therefore won't cause
problems.

We do potentially have a few latent problems scattered around because
POSIX reserves all identifiers of the form *_t, and we use some of that in
various places.  (Some of that is my fault.)

>> The hope is that _GNU_SOURCE won't do that.  Hm.  Okay, I agree that
>> it's probably the best workaround that we have; now I wonder if there's
>> a good way to put logic in configure.in so that it only adds it if it's
>> necessary.

> That's easy.  This patch is against CURRENT-20010420:

No, no, you're setting _GNU_SOURCE unconditionally on any glibc system.
This is precisely what I *don't* want to do.

_GNU_SOURCE should only be set if we actually need it for pread and
pwrite.  autoconf should make the minimal changes necessary, as a general
rule; it saves trouble down the road.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>