This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]