in reply to getc skips ahead

You need to use binmode $fh; on the filehandle, that examines the jpeg direct after the open call. It looks that your input data is in utf8 mode.
Boris

Replies are listed 'Best First'.
Re^2: getc skips ahead
by Stephen Toney (Sexton) on Aug 15, 2004 at 13:59 UTC
    Boris, That did it! It's hard to believe that the problem hasn't occurred before on tens of thousands of images, but ...

    Also, the binmode documentation does not mention getc as one of the functions it affects, so who knew?

    Anyway, many thanks for saving my bacon! Stephen

[reply]
      Also, the binmode documentation does not mention getc as one of the functions it affects, so who knew?
      I don't really think it needs to, it already says
      In other words: regardless of platform, use binmode() on binary data, like for example images.

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

      Note that the piece of information that gives it away is this: "in the problem file, [getc] returns 270, 782, 4367, 4368". You'd normally expect getc() to be reading one byte at a time, and therefore always returning numbers in the range 0..255; only if the file is being read in a different mode can larger integers be returned.

      Update: misread the details.

      Hugo

[reply]
        The original post sure sounds like he's doing getc, tell (for debugging), and something else in a loop, and the "270,782,..." are the results of the tell. The question is what is in that "something else" that advances the file pointer, and how getc's different return after binmode makes it work right.
[reply]

In Section Seekers of Perl Wisdom