[go-nuts] fmt.Printf possible bug? not sure

[sinatosk]

I'm learning go... finally got some time to use it :p

I've got a loop that constantly prints this every 500 milliseconds

fmt.Printf("%d%\n", 15)

and the output I see is this

15
missing15
missing15
missing15
missing15
missing15
missing15

I took a look at the source code in the fmt package for the doprintf
function, lines 827 - 832

how can I escape the "%" character?

thanks

[befelemepeseveze]

On May 23, 1:57 pm, sinatosk <sinat...@gmail.com> wrote:
> how can I escape the "%" character?

%%

[roger peppe]

personally i think it might be better if Printf panicked
when given a malformed format string (with an appropriately
formed error message). i can easily imagine a situation
where i corrupt some log file by changing a format string
without changing the relevant argument.

[Peter Bourgon]

On Sun, May 23, 2010 at 4:41 PM, roger peppe <rogp...@gmail.com> wrote:
> personally i think it might be better if Printf panicked
> when given a malformed format string (with an appropriately
> formed error message). i can easily imagine a situation
> where i corrupt some log file by changing a format string
> without changing the relevant argument.

What a strange situation you must have, if it's better to have your
server crash than to print something slightly malformed to the logs.

[roger peppe]

if it really matters that the server stay up, then i'll have
a recover in place anyway, and then it can provide
some notification that the problem occurred.

the recover might even be inside the log function
itself - allowing a corrupt message to turn into a
message about the corruption.

it's one of those things (like nil pointer dereferencing)
that should be a compiler error if it wouldn't complicate
things unreasonably to do so.

"what a strange system i must have, if it's better to have
my server crash than to return a zero value when dereferencing
a nil pointer" :-)

[Peter Bourgon]

On Sun, May 23, 2010 at 5:04 PM, roger peppe <rogp...@gmail.com> wrote:
> if it really matters that the server stay up,

What possible server can you write where this isn't the case? Strange
definition of 'server'. Reminds me of Ruby ;)

> a recover in place anyway, and then it can provide
> some notification that the problem occurred.

If you will put recover traps around even your log printing, then I
wouldn't like to maintain your code!

> "what a strange system i must have, if it's better to have
> my server crash than to return a zero value when dereferencing
> a nil pointer" :-)

Programmers expect nil pointer dereferences to do Bad Things.
Programmers don't expect a missing % in a string literal to crash a
program at runtime, as far as I'm aware.

(This is a bit of a derail, sorry for that.)

[andrey mirtchovski]

there was a time when a very famous and popular IRC client crashed
when passed a malformed string from channel input. oh, the fun we had
:)

[roger peppe]

On 23 May 2010 16:12, Peter Bourgon <peterb...@gmail.com> wrote:
> On Sun, May 23, 2010 at 5:04 PM, roger peppe <rogp...@gmail.com> wrote:
>> if it really matters that the server stay up,
>
> What possible server can you write where this isn't the case? Strange
> definition of 'server'. Reminds me of Ruby ;)

code started to serve a particular request, such as a CGI script,
is one example. for servers that really need to stay around, there's
often some kind of external monitor that can restart it if necessary.

> If you will put recover traps around even your log printing, then I
> wouldn't like to maintain your code!

this actually raises an interesting style issue: where is
it appropriate to put recovers? i see two acceptable
places: in an outer level loop, to recover from unexpected
runtime panics; and in an inner call, to recover from (and
deal with appropriately) a known possible error.

an example of the latter (into which category i think the
log file example would fall) is in the json code - see
unmarshal() in src/pkg/json/decode.go

> Programmers expect nil pointer dereferences to do Bad Things.
> Programmers don't expect a missing % in a string literal to crash a
> program at runtime, as far as I'm aware.

C crashes if you give a %s with no matching argument.
that's a fairly Bad Thing :-)