Internal "getline" implementation breaks nul tests

[danielhams]

Discovered by building + running tests on IRIX where by default there is no "getline" implementation - patchutils will notice and use the one from src/util.c.

Issue: Looks like the internal getline impl doesn't correctly preserve the nul chars

How to reproduce (on Linux):

perl -pi -e "s|getline|rpl_getline|g" src/*.c
perl -pi -e "s|getline|rpl_getline|g" src/*.h
export ac_cv_func_getline=no
./configure --prefix=/tmp/bananas
make
make check

That will force it use the replacement getline.

[twaugh]

I see. This is because it is based on fgets().
If you'd like to supply a simple fix I'd be happy to include it. Alternatively, maybe it needs gnulib's getline module.

[danielhams]

Hey.

'Fraid I don't have a simple solution (on IRIX we have a compatibility library that pulls in gnulib stuff like getline - but I prefer to try and get packages up and running without where possible).

You could always simply have configure bork and go no further if it doesn't find a usable getline (and remove that internal impl).

Only a suggestion of course! Thanks for your software.

[twaugh]

That's true. What will you do on IRIX?

[danielhams]

We have "libdicl" that basically imports a bunch of gnulib functionality and can be linked against (it has override headers):

https://github.com/danielhams/dicl

Then for patchutils we're forcing that with CPPFLAGS/LDFLAGS and telling autoconf it's there via env flags (we do this for getopt_long too):

https://github.com/sgidevnet/sgug-rse/blob/wipnonautomated/packages/patchutils/SPECS/patchutils.spec#L63

That unfortunately doesn't help you much though.

Edit: Although it lets you know the gnulib getline is "good enough" - all tests pass with that.

[twaugh]

Hopefully #79 fixes this.