stream of PPM images into a certain video format. The idea is that I use
a decode function similar to what image/png and image/jpeg provides that
consumes one single image from the input stream without touching the
rest of the stream, as it contains the next image immediately after the
last byte of the previous image.
I tried parsing the header of the PPM format with Fscanf. On the
documentation page of the package fmt [2] there is a notice about the
consumption behavior of Fscanf:
Note: Fscan etc. can read one character (rune) past the input they
return, which means that a loop calling a scan routine may skip some
of the input. This is usually a problem only when there is no space
between input values. If the reader provided to Fscanf implements
ReadRune, that method will be used to read characters. If the reader
also implements UnreadRune, that method will be used to save the
character and successive calls will not lose data. To attach ReadRune
and UnreadRune methods to a reader without that capability, use
bufio.NewReader.
As I read that, it is impossible to know exactly whether Fscanf takes areturn, which means that a loop calling a scan routine may skip some
of the input. This is usually a problem only when there is no space
between input values. If the reader provided to Fscanf implements
ReadRune, that method will be used to read characters. If the reader
also implements UnreadRune, that method will be used to save the
character and successive calls will not lose data. To attach ReadRune
and UnreadRune methods to a reader without that capability, use
bufio.NewReader.
rune after the last piece of the formatting string of the input. As
explained above, wrapping the input in a bufio.Reader in the decoding
function is not really a solution as I can't control at all how many
bytes are being consumed from the input stream.
Testing reveals that appending a dummy %c to the end of the formatting
string consumes a character that may or may not be pushed back otherwise
reliably. As I read the documentation this is still no guarantee that
this may change in future versions as the specification is a bit vague
on what formatting specifiers require a lookahead char.
It would be nice if somebody could confirm if the current behavior is
implementation defined or not. If not, how can I resolve this issue
without relying on implementation defined behavior?
You can find my question at Stackoverflow at [1].
Yours, Robert Clausecker
[1]: http://stackoverflow.com/q/15841257/417501
[2]: http://golang.org/pkg/fmt
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
