Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using strncpy already (2013)

randomascii.wordpress.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Stop using strncpy already (2013)

#71

Post by brucedawson »

hedora wrote: post #14

I don’t understand why silently truncating strings is considered to be acceptable practice. If you have the length of both, simply assert the length of the destination is <= the length of the source. Problem solved (bugs become obvious in testing).

strcpy_s does this. It has a template variant to infer the length of the destination buffer and it will terminate the program if the source string is too large.

If the destination buffer doesn't have a fixed length then it will fail to compile.

This is similar to your suggestion with these improvements: - Template deduction of the destination size is done - this is essential to avoid bugs - Detection of overwrites is done in release builds as well as during testing - Detection of overwrites is automatic - it doesn't require manually adding asserts to call sites - strcpy_s exists in some standard libraries

Re: Stop using strncpy already (2013)

#72

Post by gnulinux »

pjmlp wrote: post #62
jstimpfle wrote: post #11

Earlier quoted context omitted.

What are the good alternatives? You can either copy memory manually, or have a system like C++'s that causes lots of tiny allocations, which is very inefficient. Both in space and time. You can also opt for immutable strings to be able to share strings more conveniently and efficiently, at the cost of O(n^2) build time (where automatic optimizations fail) or decreased convenience (explicit string-stream aka string bu…

You care about that after a profiler proves that it is actually a problem to the expected delivery SLAs for the application. Micro-optimizing each line of C code based on gut feeling is not an option if quality matters.

This is a horrible stance and this is repeated like broken record. Please stop saying this? A good software engineer should know (1) a suitable data structure to solve the problem in hand (2) algorithms that have certain asymptotic characteristic that makes most sense for the problem (what assumptions can you make). "Premature optimization is the root of all evil" can be used for and only for "optimization". Choosing the right data structure is never an optimization, it's a design choice. You can't just start coding everything with a linked list and then optimize bottlenecks, that's just not how it works.

Re: Stop using strncpy already (2013)

#73

Post by pjmlp »

gnulinux wrote: post #72
pjmlp wrote: post #62

Earlier quoted context omitted.

You care about that after a profiler proves that it is actually a problem to the expected delivery SLAs for the application. Micro-optimizing each line of C code based on gut feeling is not an option if quality matters.

This is a horrible stance and this is repeated like broken record. Please stop saying this? A good software engineer should know (1) a suitable data structure to solve the problem in hand (2) algorithms that have certain asymptotic characteristic that makes most sense for the problem (what assumptions can you make). "Premature optimization is the root of all evil" can be used for and only for "optimization". Choosing…

As you say "A good software engineer should know a suitable data structure to solve the problem in hand".

So I expect a good software engineer on my team to be able to design a data structure where the fact that a linked list is being used doesn't hinder to change it afterwards to an array, a B-Tree or what have you.

Without changing a single line of client code I might add.

Such good software engineer will certainly had attended an algorithms and data structures class on their CS degree and be aware of architecture designs based on Abstract Data Types.

Yes, even in C with its flaky translation units instead of proper module systems, it is possible to implement Abstract Data Types application architectures, which any good software engineer can easily tackle.

And for those that aspire to reach that level, here are a few examples.

"Algorithms + Data Structures = Programs" by Niklaus Wirth, 1st edition is Modula-2, the 2nd in Oberon

"Introduction to Algorithms" by Thomas Cormen, Clifford Stein, Ronald Rivest, Charles Leiserson

"Abstract data types and Modula-2: a worked example of design using data abstraction" by Richard Mitchell

"Abstract Data Types in Modula-2" by Rachel Harrison

"Abstract Data Types and Algorithms" by Azmoodeh, Manoochchr

Re: Stop using strncpy already (2013)

#74

Post by pjmlp »

jstimpfle wrote: post #64
pjmlp wrote: post #62

Earlier quoted context omitted.

You care about that after a profiler proves that it is actually a problem to the expected delivery SLAs for the application. Micro-optimizing each line of C code based on gut feeling is not an option if quality matters.

It's not about the code, but about choice of data structure. Unfortunately that has to be planned ahead to some degree. You can't really optimize it after the fact. Typically a choice affects more than a single line of code, but that doesn't mean "microoptimizing every line of code", which is obviously a bad idea.

Sure you can, that is what Abstract Data Types architecture design is all about.

Naturally, when one creates struts and accesses the fields directly there is no way out of a bad design.

Re: Stop using strncpy already (2013)

#75

Post by jstimpfle »

pjmlp wrote: post #74
jstimpfle wrote: post #64

Earlier quoted context omitted.

It's not about the code, but about choice of data structure. Unfortunately that has to be planned ahead to some degree. You can't really optimize it after the fact. Typically a choice affects more than a single line of code, but that doesn't mean "microoptimizing every line of code", which is obviously a bad idea.

Sure you can, that is what Abstract Data Types architecture design is all about. Naturally, when one creates struts and accesses the fields directly there is no way out of a bad design.

That's a pipe dream. There are a handful of successful abstractions, like streams or associative containers, or strings for that matter. Even those quickly get too abstract for serious use, and you need to actually expose what's really happening to make sensible choices, because there are vastly different kinds of streams or containers (or even strings), because, well, those are abstractions.

Other more far reaching design choices could be: when and how much precomputation is done, data loading strategies, data-flow oriented vs control flow oriented, threading strategies, etc. You can't hide these choices behind a name. They deeply affect the structure of the program.

Re: Stop using strncpy already (2013)

#76

Post by gnulinux »

pjmlp wrote: post #73
gnulinux wrote: post #72

Earlier quoted context omitted.

This is a horrible stance and this is repeated like broken record. Please stop saying this? A good software engineer should know (1) a suitable data structure to solve the problem in hand (2) algorithms that have certain asymptotic characteristic that makes most sense for the problem (what assumptions can you make). "Premature optimization is the root of all evil" can be used for and only for "optimization". Choosing…

As you say "A good software engineer should know a suitable data structure to solve the problem in hand". So I expect a good software engineer on my team to be able to design a data structure where the fact that a linked list is being used doesn't hinder to change it afterwards to an array, a B-Tree or what have you. Without changing a single line of client code I might add. Such good software engineer will certainly…

Your comment still doesn't make sense, even though you decided to choose a certain ADS and then latee decide on the implementation later based on empirical performance data, this is still not unusual. For (1) this is not how people write C. There are ADS libraries in C with which you wouldn't need need to use any DS that you can't change but this is not a usual way to write C code. This will also come with the overhead of pointer indirection and worse cache performance since all your objects will be void* stored in the DS (unless you m4 or macro generate your DS with all datatypes. This is what linux does for example, and I sometimes use this technique too, but this hardly the usual way to write C code). And (2) usually complex problems require special enough datastructures that it doesn't make much sense talk about ADSs. Everyone can code basic foobar with List interface then decide to use ArrayList or LinkedList based on performance. It's more interesting when the programmer decides to use a set, a hash map, a bloom filter etc to solve the problem as any other type wouldn't make sense.

Re: Stop using strncpy already (2013)

#77

Post by rurban »

AdmiralAsshat wrote: post #7

In principle, I feel like "Ignore the language-provided standard libraries and use this little macro I wrote in all your code" is bad advice. If the standard libs are that bad , the community should really lobby for the inclusion of a "safe" string copy into the C standard. Failing that, use a battle-tested third-party library like bstrlib[0]. [0] http://bstring.sourceforge.net/

Rather use safeclib. It is C11. It has a safe version of the wrongly spec'ed truncating functions, in this case strncpy_s. This version guarantees NULL termination.

https://rurban.github.io/safeclib/

Re: Stop using strncpy already (2013)

#78

Post by rurban »

bitwize wrote: post #40
AdmiralAsshat wrote: post #7

In principle, I feel like "Ignore the language-provided standard libraries and use this little macro I wrote in all your code" is bad advice. If the standard libs are that bad , the community should really lobby for the inclusion of a "safe" string copy into the C standard. Failing that, use a battle-tested third-party library like bstrlib[0]. [0] http://bstring.sourceforge.net/

strcpy_s, anyone?

It is even C11: https://github.com/rurban/safeclib/blob/master/src/str/strcp...

Re: Stop using strncpy already (2013)

#79

Post by rurban »

IChooseYou wrote: post #20
gp7 wrote: post #3

Two years after this post, the Linux kernel added strscpy, the api of which is equivalent to the safe strncpy in this post. Internally, it stops copying once it reaches the null terminator. https://lwn.net/Articles/659214/

Also Microsoft's strncpy_s has been around forever.

But Microsoft's strncpy_s is unsafe. My safeclib also had the unsafe versions behind the non-default ./configure --enable-unsafe switch.

But this year I decided to make them safe instead. In this case the spec is broken.

Re: Stop using strncpy already (2013)

#80

Post by pjmlp »

gnulinux wrote: post #76
pjmlp wrote: post #73

Earlier quoted context omitted.

As you say "A good software engineer should know a suitable data structure to solve the problem in hand". So I expect a good software engineer on my team to be able to design a data structure where the fact that a linked list is being used doesn't hinder to change it afterwards to an array, a B-Tree or what have you. Without changing a single line of client code I might add. Such good software engineer will certainly…

Your comment still doesn't make sense, even though you decided to choose a certain ADS and then latee decide on the implementation later based on empirical performance data, this is still not unusual. For (1) this is not how people write C. There are ADS libraries in C with which you wouldn't need need to use any DS that you can't change but this is not a usual way to write C code. This will also come with the overhe…

We will have to agree to disagree, then.

Sofware quality and meeting delivery SLAs should trump micro-optimizing cache access per code line.

So if SLAs define 100ms per access, no need to go crazy making everything under 5ms.

Thankfully, the Linux foundation has another view on the matter.

https://www.youtube.com/watch?v=XfNt6MsLj0E

Post reply on HN