Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread fgergo
(This time reply to list. Sorry Brian.)

On Tue, Feb 6, 2024 at 3:03 PM 'Brian Candler' via golang-nuts
 wrote:
>
> > Thanks! In addition to that, It also helps with code with upper limit
> > memory-requirement, which fmt.Sprintf() can't.
>
> If you're processing data from untrusted sources, then you probably ought to 
> validate it first.
>
> > How to use a limiting
> > io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
> > memory usage?
>
> Proof-of-concept: https://go.dev/play/p/kJabvvTzFH0
>
> I don't know under what circumstances this would cause Fprintf to terminate 
> early; it depends on how much buffering it does internally. I would guess 
> that a large single argument like "%s" would be treated as a single entity, 
> and very likely allocate an intermediate buffer of the full size.
>
> If this matters in your use case, then I think you shouldn't be using Sprintf 
> and friends.
I should probably limit memory usage outside of the process anyway.
A bit unexpected, though I'm not complaining.
cheers

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BctqrraLr%3Dh%2BXuPGOzgfu%3DQD0O_abqMm4bSX6LPPPtGMxwejA%40mail.gmail.com.


Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread 'Brian Candler' via golang-nuts
> Thanks! In addition to that, It also helps with code with upper limit
> memory-requirement, which fmt.Sprintf() can't.

If you're processing data from untrusted sources, then you probably ought 
to validate it first.

> How to use a limiting
> io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
> memory usage?

Proof-of-concept: https://go.dev/play/p/kJabvvTzFH0

I don't know under what circumstances this would cause Fprintf to terminate 
early; it depends on how much buffering it does internally. I would guess 
that a large single argument like "%s" would be treated as a single entity, 
and very likely allocate an intermediate buffer of the full size.

If this matters in your use case, then I think you shouldn't be using 
Sprintf and friends.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/960530e8-b872-4c86-8232-8fad8bd9d76cn%40googlegroups.com.


Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread fgergo
On Tue, Feb 6, 2024 at 12:18 PM 'Brian Candler' via golang-nuts
 wrote:
>
> The C functions are mainly there to prevent overrunning already-allocated 
> buffers, which isn't an issue with Go.
Thanks! In addition to that, It also helps with code with upper limit
memory-requirement, which fmt.Sprintf() can't.
Though I can live with careful coding and not using Sprintf() in this
case, I just hoped possibly somebody else already thought about
needing that.

...
> You could make a custom type which implements io.Writer and truncates at a 
> given size, and pass it to fmt.Fprintf
IIUC this sounds similar to what I'm asking for. How to use a limiting
io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
memory usage?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bctqro%3D9St0Qj_A-UGEUowvjK1OHX%3DQJ2QiBAMQdxZBwvHM%2Bw%40mail.gmail.com.