Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #28446

Re: snprintf return value

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: snprintf return value
Date 2018-12-12 09:09 +0100
Organization A noiseless patient Spider
Message-ID <puqfon$vde$1@dont-email.me> (permalink)
References <pulekl$n55$1@dont-email.me> <HbBPD.1230070$Vl2.662518@fx46.iad> <VLmdnSQkm65OdZLBnZ2dnUU78d2dnZ2d@supernews.com> <nQXPD.950180$ZJ2.2926@fx33.iad>

Show all headers | View raw


On 12/12/18 00:34, Clifford Heath wrote:
> On 12/12/18 3:41 am, Phil Hobbs wrote:
>> On 12/10/18 4:49 PM, Clifford Heath wrote:
>>> On 10/12/18 9:20 pm, pozz wrote:
>>>> The return value of snprintf() is useful if you want to dynamically
>>>> reallocate the buffer so it can store all the string. In my case I
>>>> would prefer to truncate the string at the end of the static buffer.
>>>
>>> I'd be seriously asking yourself why you prefer that.
>>> Arbitrary unexpected truncation of data should not be tolerated.
>>>
>>> Clifford Heath.
>>
>> Well, overrunning a buffer is a bug, so it's just a choice of which
>> type of misbehaviour you prefer.  If I'm writing to some logfile, for
>> instance, truncating the message is a lot better than overwriting memory!
> 
> Right, overflow protection is important. So is data integrity.
> 
> So make sure you have a big enough buffer for your data, possibly by
> truncating the data before you snprintf(), or by using %.23s or the
> like. Either way you should handle truncation *deliberately*, not by
> simply clamping to a buffer length.
> 

Not all data is equally valuable.  And not all data is of a size that
you know you can handle fully.  I have no idea what the OP's original
needs are here, but a prime example is, as Phil said, a log file.  Often
the details of what are in the log file are not critical - but avoiding
buffer overruns or limiting the bandwidth used /is/ critical.  So
techniques like truncation or rate limiting are entirely reasonable here.


Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

snprintf return value pozz <pozzugno@gmail.com> - 2018-12-10 11:20 +0100
  Re: snprintf return value Reinhardt Behm <rbehm@hushmail.com> - 2018-12-10 18:24 +0800
    Re: snprintf return value pozz <pozzugno@gmail.com> - 2018-12-10 11:32 +0100
      Re: snprintf return value Philipp Klaus Krause <pkk@spth.de> - 2019-01-01 12:59 +0100
  Re: snprintf return value David Brown <david.brown@hesbynett.no> - 2018-12-10 13:15 +0100
  Re: snprintf return value Clifford Heath <no.spam@please.net> - 2018-12-11 08:49 +1100
    Re: snprintf return value Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-12-11 11:41 -0500
      Re: snprintf return value Clifford Heath <no.spam@please.net> - 2018-12-12 10:34 +1100
        Re: snprintf return value David Brown <david.brown@hesbynett.no> - 2018-12-12 09:09 +0100
          Re: snprintf return value Clifford Heath <no.spam@please.net> - 2018-12-12 21:38 +1100
        Re: snprintf return value Les Cargill <lcargill99@comcast.com> - 2018-12-30 11:23 -0600
  Re: snprintf return value Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-12-11 00:47 +0100
    Re: snprintf return value Clifford Heath <no.spam@please.net> - 2018-12-11 13:31 +1100

csiph-web