FAQ
I am writing a decoder for PPM images for an application that encodes a
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 a
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rémy Oudompheng at Apr 5, 2013 at 8:49 pm

    On 2013/4/5 Robert Clausecker wrote:

    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 read the line into a buffer, as a first step (using
    bufio.Reader.ReadBytes/ReadSlice for example), then use fmt.Fscanf on
    a bytes.Reader set to read this line.

    Rémy.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 5, '13 at 8:33p
activeApr 5, '13 at 8:49p
posts2
users2
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase