-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal "getline" implementation breaks nul tests #45
Comments
I see. This is because it is based on |
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. |
That's true. What will you do on IRIX? |
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): 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. |
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):
That will force it use the replacement getline.
The text was updated successfully, but these errors were encountered: