Artsize still not quite right in CURRENT
qralston+ml.inn-workers at andrew.cmu.edu
Sun Apr 22 00:02:07 UTC 2001
On 20 Apr 2001, Russ Allbery wrote:
> 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.
INN doesn't actually perform the typedefs anywhere; there's logic to
do it in the middle of innfeed/misc.h, but the typedefs are
conditional on the DO_NEED_U_INT symbol being set, which never happens
(at least in CURRENT-20010420). So pretty much everything in the
innfeed subdir blows up if the system headers don't perform the
Outside of the innfeed subdir, there's one other occurrence:
innd/rc.c: In function `GoodIdent':
innd/rc.c:124: `u_short' undeclared (first use in this function)
> 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.
Iff the feature-test macros were deprecated; otherwise, INN would
never see the LOCK_READ, LOCK_WRITE, or LOCK_UNLOCK symbols.
But this is a matter of perspective, I guess.
> (Patches for this problem are very much welcome.)
I actually already went ahead and made a patch (prefixing the LOCK_*
symbols with "INN_" and prefixing the lock_file and lock_range
functions with "inn_"), but the changes are pervasive, and will most
likely break any patches in the pending queue.
If you can let me know when all the patches in the pending queue are
cleared out, I'll go ahead and remake the patch. I'll also replace
all instances of the BSD typedefs with the corresponding vanilla
definitions (e.g.: "u_short" -> "unsigned short"). I'll also turn on
gcc's -Wall and fix up some missing #include and typdef stuff; there
are a fair number of places where INN isn't doing the right thing.
> 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.
Hmmm. I was generally aware of RMS's attitude, but I wasn't aware the
feature-test macros were mandated.
> 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 one way to do it, but that won't help if something informal is
later standardized; most likely, you'll be stuck with the same header.
(But, as you said, it's mostly a moot point now.)
> 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
No. _GNU_SOURCE should be defined if any symbol or function in set |F|
requires it, where |F| contains at least pread and pwrite. We do not
know what other symbols/functions are in |F|. Determining what other
symbols/functions are in |F| is probably a non-trivial task.
But it seems to me that the easiest and most correct choice of action
is to simply define _GNU_SOURCE in cases where the C library being
used for linking is glibc. This is specifically what glibc
recommends: that _GNU_SOURCE be used in new programs. It also seems
to me to be compatible with your own arguments: all functionality of
the standard C library should be visible; feature-test macros are
mandated. That's what defining _GNU_SOURCE gets you.
But clearly, you don't feel that way. Could you help me understand
your position? Because, at this point, I honestly don't understand
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
More information about the inn-workers