Artsize still not quite right in CURRENT

Alex Kiernan alexk at demon.net
Wed Apr 18 12:31:39 UTC 2001


Alex Kiernan <alexk at demon.net> writes:

> davidsen at tmr.com (bill davidsen) writes:
> 
> > In article <721yqsez2t.fsf at nd1.eng.demon.net>,
> > Alex Kiernan  <alexk at demon.net> wrote:
> > | 
> > | davidsen at tmr.com (bill davidsen) writes:
> > 
> > | >   In any case, if that's the problem, unless there's a huge gain in
> > | > {something} by using pread, perhaps we can revert the code, or put in a
> > | > conditional, or whatever.
> > | > 
> > | 
> > | How about writing a configure test which checks for broken
> > | implementations and falls back to the version in lib (which emulates
> > | using lseek & read, so should work).
> > 
> > I'm in favor of it, but it's an interesting test to devise. I think we
> > want to determine if the kernel or library is broken first.
> > 
> 
> Can you try this, building it with appropriate 64 bit flags & running
> it on a file system which allows 64 bit operations:
> 

I found a RedHat 7 box to play on here, and whilst it needs a #include
<stdint.h> to get the uint32_t type, when run it gives:

pread broken - wrote badc0de, read deadbeef

[BTW someone who knows Linux better than me - should this build line
do the right thing:

gcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 checkpread.c]

I'll check out whether pwrite is similarly affected and write some
autoconf tests.

An alternative approach would appear to be to drop a #define pread
pread64 into config.h which similarly seems to fix the problem.

For reference the box is running 2.4.3-ac7, with (I think) a glibc 2.2
derived libc (is there some way of getting it to report the library
version info?)

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC


More information about the inn-workers mailing list