On Mon, Oct 29, 2018 at 01:28:02PM -0700, Rick Moen wrote: > Quoting Daniel Taylor (ran...@argle.org): > > > They do, but that's not an excuse for using strcpy(). > > > > Which they did. > > Of course, obviously. You _are_ aware I was merely trying to help by > pointing out that strncpy (etc.) is suboptimal, right?
Well, it is possible to use strcpy() right. On the other hand, _every_ use of strncpy() for a C string is a bug. There are three possibilities: A> either the string does overflow B> or it doesn't C> you know the string's length beforehand If A>, then you have a nasty non-terminated string that can't be passed to any function expecting a C string (resulting in a read overflow). Yay a security hole, crash, or at least corrupted data. If B>, you waste time clearing the buffer. As there's a static size (otherwide it'd be C>), there's a good deal of headway. In a typical case (judging from programs I looked at) you have a string of twelve bytes in a buffer of 2K... and a clear every single copy. Yay significant slowdown. If C>, you should have used memcpy() instead. Scanning for a 0 is slower than a blind loop. On the other hand, snprintf(), strlcpy() and so on do what naive intuition says strncpy() would do. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came ⠈⠳⣄⠀⠀⠀⠀ together with silk (judging by today's amber stalls). _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
