Re: adding getdelim(3) and getline(3) to libc

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 13 Jul 2009 17:32:11 +0200
    From:        Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
    Message-ID:  <20090713153211.GA26513%britannica.bec.de@localhost>

  | It is somewhat reasonable to assume that libc and /usr/include match.

That I agree with, I'm less confident about /usr/include/sys though
(though that's certainly likely to be more stable than the actual kernel
version).

  | As the kernel version is part of /usr/include/sys/param.h, it can be
  | used for conditionals.

If it were being done this way, then that would be towards the lesser
end of the evil scale, but sill evil.   Unfortunately much of the stuff
around uses uname output tests which is much much worse.

For anything like this, you're clearly doing NetBSD specific code, you
can't really expect a test for __NetBSD_Version__ being >= some value
to work anywhere else.   If NetBSD specific is good enough, then a
better method would be to simply define a preprocessor symbol in
whatever header file is expected to define getline() (etc), (no idea
which, stdlib.h or something I guess) and then that could be tested
by code that needs to know.

At least that way there's a method that other systems could adopt
without too much pain, which __NevBSD_Version__ is never going to be.
And what's more, if you're on a system with getline (etc) but without
the magic symbol defined, it is possible to just compile with -DWHATEVER
and handle it that way.

Most pkgsrc code is probably using autoconf anyway, for that, the correct
test is to actually compile code that uses the function in question and
see if it "works" - that's how it tests everything else, and it's a method
that (cross compiling excepted) works cleanly.

kre