There's a bug in Darwin6.5's readdir that shows up only with
338 or more files.
Fix a bug in this test: `cd $pwd' (not to `..'), now that $tmp
has two components.
(dump_remainder): Move two declarations `down' into the scope
where they are used.
(xlseek): Return the resulting offset.
(file_lines): Rename parameter, file_length, to end_pos.
(pipe_lines): Don't coerce safe_read return value to `int'.
Adapt tests accordingly.
(pipe_bytes) [struct charbuffer] (nbytes): Change type from `int'
to `unsigned int'.
Change type of `total_bytes' from `int' to `size_t',
since the former wouldn't always be wide enough.
Don't coerce safe_read return value to `int',
and adapt tests accordingly.
Now that testing for a read error no longer involves
using `tmp', handle that case *after* freeing `tmp'.
(start_bytes): Clean up.
(tail_bytes): Now that `n_bytes' may be larger than
OFF_T_MAX, test for that condition and, if it's true, don't
use lseek optimizations.
(parse_options): Don't fail just because N_UNITS is larger than
the maximum size of a file -- tail may be applied to an input
stream (e.g., a pipe) with more data than that.
is not defined, don't run the test, and don't use the wrapper.
Otherwise, on the Hurd, it would take a long time to create
and remove a hierarchy about 4000 levels deep.
Based on a patch from Robert Millan.
<http://mail.gnu.org/archive/html/bug-coreutils/2003-04/msg00070.html>.
* doc/coreutils.texi (printf invocation): It's \NNN in the format,
\0NNN in the %b operand.
* src/printf.c (usage): Likewise.
(print_esc): New arg OCTAL0 to specify whether \0NNN or \NNN
is desired. All uses changed. Behave like Bash printf if %b
operand uses \NNN where the initial N is not 0.
