This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH RESEND] zic, various tests: use LFS I/O functions explicitly where needed
On 26 Jun 2017, Paul Eggert stated:
> Nick Alcock wrote:
>> you are now depending on the
>> order of error-checks in the kernel's stat implementation (that it
>> returns EOVERFLOW only after it's had the opportunity to return ENOENT,
>> so that EOVERFLOW -> !ENOENT)
> No, because ENOENT and EOVERFLOW are mutually exclusive regardless of
> the order of error checks, as the stat buffer of a nonexistent file
> cannot possibly overflow. So there is no dependency, and no bug here.
Oh, true. I was thinking of an EOVERFLOW from the directory, but of
course if you get that you cannot possibly be issuing a stat for a
nonexistent file at the same time!
>> Maybe I should have fallen back on adding to tz-cflags?
> That would be better, in that glibc source would continue to match
> tzcode exactly. It doesn't hurt correctness to compile zic.c with
> -D_FILE_OFFSET_BITS=64, and doing that should make 32-bit zic run a
> tiny bit faster on directories whose inode numbers (or sizes,
> timestamps, ...) don't fit in 32 bits. So it is a tiny performance win
> even if it is not a bug fix.
Well, we've seen zic fail with bizarre error messages in this situation
already. So I'd call it a bugfix. :)
(Did you mean zdump, which is in tz-cflags but is not affected by this?)