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

Groups > comp.lang.c > #141801

Re: Safer and more convenient strcpy()

Show all headers | View raw

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Thu, 2019-03-07, Malcolm McLean wrote:
>> On Thursday, 7 March 2019 16:12:28 UTC, Scott Lurndal  wrote:
> ...
>>> How is that better than
>>> 
>>>    size_t numbytes = snprintf(dst, sizeof(dst), "%s", src);
>>> 
>>> safe, nul-byte terminated and returns an indication of whether
>>> src was larger than dst.
>> ?
>> Because if you want to make more than one call, to concatenate strings,
>> you have to recalcuate the size parameter, which is where errors 
>> could creep in.
> 
> On the other hand, snprintf() itself has good support for
> concatenating strings.

snprintf has more complex error conditions, though. For example, in glibc
snprintf is implemented using the stdio subsystem, effectively invoking
something like fprintf through a specialized FILE handle. Initialization of
the internal data structures can require dynamic allocation and so even a
simple format string like "%s" can return ENOMEM. AFAIU, floating point
specifiers can require dynamic allocation in most (all?) snprintf
implementations.

And then there's the matter that snprintf takes an int parameter for the
buffer size as well as returning an int, raising the spectre of unexpected
and undefined conversions and overflows. Indeed, the two issues
combined--integer conversions and managing error conditions--makes the above
example snprintf usage poorly written code, IMO.

Personally I think strlcpy and strlcat hit a sweet spot--sufficient and safe
for simple string management in C. More complex scenarios (i.e. efficient
Big-O concatenation for large strings) are usually better solved with a
proper buffer library with interfaces tailored for the use case. Though, I
wouldn't fault code for relying snprintf for basic string copying and
concatenation, presuming they use it correctly.

One can spend an eternity refining string interfaces trying to fill the gap,
as exemplified in this and countless other threads. (How many times has C++
tweaked the semantics of std::string?) But why bother? Most of the C library
is suboptimal (as are most standard libraries in most languages, for that
matter), yet most of us understand that consistency and uniformity make it
cost effective to continue using those interfaces.

String management, logging, configuration parsing--these are abstraction
blackholes. The only way to win is to not play.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-06 03:45 -0800
  Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-06 03:58 -0800
    Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-06 04:31 -0800
      Re: Safer and more convenient strcpy() "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2019-03-06 05:18 -0800
        Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-06 13:03 -0800
          Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-06 16:51 -0800
            Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-07 07:40 -0800
              Re: Safer and more convenient strcpy() scott@slp53.sl.home (Scott Lurndal) - 2019-03-07 16:12 +0000
                Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-07 08:28 -0800
                Re: Safer and more convenient strcpy() scott@slp53.sl.home (Scott Lurndal) - 2019-03-07 16:51 +0000
                Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-07 09:31 -0800
                Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-07 11:17 -0800
                Re: Safer and more convenient strcpy() Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-07 22:35 +0000
                Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-07 15:32 -0800
                Re: Safer and more convenient strcpy() scott@slp53.sl.home (Scott Lurndal) - 2019-03-08 14:29 +0000
                Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-08 07:09 -0800
                Re: Safer and more convenient strcpy() Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-08 15:39 +0000
                Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-08 07:56 -0800
                Re: Safer and more convenient strcpy() Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-09 08:12 +0000
                Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 15:51 -0800
                Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 16:38 -0800
                Re: Safer and more convenient strcpy() Keith Thompson <kst-u@mib.org> - 2019-03-07 18:32 -0800
                Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 20:00 -0800
                Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-08 04:15 -0800
            Re: Safer and more convenient strcpy() "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2019-03-07 12:15 -0800
      Re: Safer and more convenient strcpy() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:12 -0800
  Re: Safer and more convenient strcpy() mark.bluemel@gmail.com - 2019-03-06 08:27 -0800
  Re: Safer and more convenient strcpy() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:22 -0800
  Re: Safer and more convenient strcpy() Rosario19 <Ros@invalid.invalid> - 2019-03-07 09:10 +0100
    Re: Safer and more convenient strcpy() Rosario19 <Ros@invalid.invalid> - 2019-03-07 09:12 +0100
      Re: Safer and more convenient strcpy() mark.bluemel@gmail.com - 2019-03-07 00:55 -0800
  Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 16:09 -0800
    Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-08 04:04 -0800
    Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-15 04:40 -0700
      Re: Safer and more convenient strcpy() nobody@example.org (Scott) - 2019-04-16 03:33 +0000
        Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-16 05:35 -0700
          Re: Safer and more convenient strcpy() nobody@example.org (Scott) - 2019-04-17 01:19 +0000
            Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-17 05:35 -0700
              Re: Safer and more convenient strcpy() nobody@example.org (Scott) - 2019-04-17 16:59 +0000
                Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-17 23:40 -0700
  Re: Safer and more convenient strcpy() Philipp Klaus Krause <pkk@spth.de> - 2019-03-20 11:10 +0100
    Re: Safer and more convenient strcpy() Philipp Klaus Krause <pkk@spth.de> - 2019-03-20 11:13 +0100

csiph-web