in reply to Re^2: Possible issue with read() in (some builds of) 5.8.0?
in thread Possible issue with read() in (some builds of) 5.8.0?

... identical data files ... which have been copied to a test location, not each host's live wtmp file.

Oh. That discounts that idea. My apologies.

The other possibility that comes to mind as a result of your expanded description of the problem, is that some parts of the file are being interpreted as unicode with the result that multiple bytes are being read and treated as a single character.

The way to verify that possibility is to ensure that the file is being treated as 'raw' using the 3-arg open:

open(WTMP, '<:raw', './wtmp') || die "Unable to open wtmp file: $!\n";

Or binmode

open(WTMP, './wtmp') || die "Unable to open wtmp file: $!\n"; binmode( WTMP, ':raw' )

Either way should tell you if this is the problem.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^4: Possible issue with read() in (some builds of) 5.8.0?
by dsheroh (Monsignor) on May 22, 2006 at 20:34 UTC
    Excellent - worked like a charm! Unicode had crossed my mind (since it was introduced in 5.8.0, bugs in it seemed likely, plus it would explain why the bytes consumed varied from record to record), but I didn't see anything in the hex dumps of the data which looked likely to trigger interpretation as unicode.

    I'll have to remember that :raw... I've heard about 3-argument open as a security measure (to protect from user-entered filenames starting with ">", etc.), but this is the first time I've seen it used for anything more than that.

    Thanks again!