confused when they can't find it), but leave the reference to it
as being a standard filename (which doesn't imply that it exists).
Discussed with: jkh
Enabled this new feature with the makefile variable GREP_LIBZ. If
you don't like it, compile with `make GREP_LIBZ='.
grep + zlib has several advantages:
- the shell script zgrep(1) will be basically a one line
exec grep -Z "$@"
- no shell script, no bugs. The current zgrep implementations
have many bugs and some grep options are no supported.
- no shell script, no security risks.
- it is a magnitude faster than a shell script
Also fixed:
0 -> STDIN_FILENO
Close a file descriptor only if the open call was successfully. It does
not hurt for the open(2) function, but the gzclose(3) function
died in free() to free up (not) allocated memory.
following "panic:" or "Fatal trap". `panicstr' is still printed,
although it is redundant if there is a valid message buffer and
incomplete if it contains `%'s. I think the awk command belongs
here and not in a script since a standard format with complete
messages is good for bug reports.
emacs a.out file, self-generated by emacs's "unexec" function in
"unexsunos4.c", is invalid. In particular, its "_end" symbol has
the wrong value. The dynamic linker was using the value of that
symbol to initialize its sbrk break level.
The workaround is to peek at the executable's a.out header in
memory, and calculate what "_end" should be based on the segment
sizes.
I will work out a fix for emacs and send it to the FSF. This
dynamic linker workaround is still worthwhile, if only to avoid
forcing all emacs users to build a new version.
Note: xemacs gives a bogus warning at startup, for related reasons.
The warning is harmless and can safely be ignored. I will send a
patch to the xemacs maintainers to get rid of it, and meanwhile
add a patch file to our port.
things so that it uses the same malloc as is used by the program
being executed. This has several advantages, the big one being
that you can now debug core dumps from dynamically linked programs
and get useful information out of them. Until now, that didn't
work. The internal malloc package placed the tables describing
the loaded shared libraries in a mapped region of high memory that
was not written to core files. Thus the debugger had no way of
determining what was loaded where in memory. Now that the dynamic
linker uses the application's malloc package (normally, but not
necessarily, the system malloc), its tables end up in the regular
heap area where they will be included in core dumps. The debugger
now works very well indeed, thank you very much.
Also ...
Bring the program a little closer to conformance with style(9).
There is still a long way to go.
Add minimal const correctness changes to get rid of compiler warnings
caused by the recent const changes in <dlfcn.h> and <link.h>.
Improve performance by eliminating redundant calculations of symbols'
hash values.
Implemented reading of %fs and %gs from core files.
Print weird floating point values better. We have to convert long
doubles to doubles here because of limitations and bugs in printf()
and floatformat_to_double() (long doubles aren't really supported
and naive converion to double causes exceptions). Conversion loses
information about weird formats (everything becomes a quiet NaN),
and printf() doesn't know about different types of NaNs anyway.
plain 0 should be used. This happens to work because we #define
NULL to 0, but is stylistically wrong and can cause problems
for people trying to port bits of code to other environments.
PR: 2752
Submitted by: Arne Henrik Juul <arnej@imf.unit.no>
