5 ms·

There is also strscpy [1] which behaves like the authors use of memccpy except the former doesn’t require manually passing the null terminator as an argument.

• oersted 2y ago
  C programmers like their overly concise naming schemes don’t they… How do you expect a user to guess the subtle differences in behavior between strncpy, strlcpy and strscpy? Sure screens were smaller before and you didn’t have autocomplete, but reaching out for documentation was also harder, and there was less of it. I guess “real programmers” memorize libc down to every detail and never use dependencies they didn’t write themselves.
  • acuozzo 2y ago
    > C programmers like their overly concise naming schemes don’t they It's a holdover from 1970s-era linkers, many of which required each exported symbol to be unique within the first six or so characters.
    • oersted 2y ago
      This is helpful, thanks. And I assume that no one imagined that you would need more variants of strcpy to begin with, strncpy is a pretty good name too, and then it's hard to break the pattern. Similar situations with lots of other names. I just wish that C style used fewer single char names and hard-to-decipher acronyms. Smart programmers can't read minds either...
  • JohnMakin 2y ago
    > How do you expect a user to guess the subtle differences in behavior between strncpy, strlcpy and strscpy? man (strxcopy)
  • lanstin 2y ago
    In the 90s, as a working C programmer, I would make it a practice to read thru man 2 and man 3 from time to time, as well as to read all the options for gcc. The man pages were pretty good at covering the differences, if not all the implications of the differences. And to this day I strive to minimize the dependencies of my software - any dependency you have is an essentially unbounded cost on the maintenance side. I used to sign up for the security mailing list for all the dependencies, and would expect to have to follow all the drama and politics for the depenencies in order to have context on when to upgrade and when not too. With Go I don't do that, but with Python I sometimes still do. And I've been reading the main R support email list for ever. I still think that a periodic reading of lwn.net is an essential part of being a responsible programmer. I will also say, reading the article reminds me of the terror of strings in C without a good library and set of conventions, and why Go (and presumably all other modern languages) is so much more relaxing to use. The place I worked have everything length prefixed and by the end of the 90s all the network parsing was code generated from protocol description files, to remove the need for manually writing string copying code.
    • oersted 2y ago
      I was somewhat dismissive, but I agree that this way of thinking about dependencies is the right approach for systems programming. And it is fair to expect that users will read the manual in detail for any tool or library they adopt in the contexts where C is used. It's just a bit frustrating to deal with so many names that are hard to understand and remember. C-style naming forces you to refer to the docs more often, and the docs are usually more sparse and less accessible than in other ecosystems. Man pages are relatively robust and they were a delight back in the day, but they have not been the gold standard for decades, and the documentation conventions for third-party libraries tend to be quite weak.
      • lanstin 2y ago
        A distressing number of softwar engineers have overly accurate memories and don't notice when things become excessively cryptic or arcane. However the implementations being much more open source now means a lot of bad documentation can be overcome with code reading or, if needed, stepping thru the code with a debugger. Wrong documentation is still expensive. I have a bitter taste in my mouth from integrating with OpenTelemetry Go libraries. It seems to be sorted now in 1.27and q 28 but 1.24 and for a few versions the docs were wrong, the examples were not transferable, and it took 5x the time it should have.
  • layer8 2y ago
    > How do you expect a user to guess the subtle differences Software developers should never rely on guessing. Always, always read the specification.
    • oersted 2y ago
      You are right, perhaps "guess" is the wrong term, I meant that it is unreasonably hard to identify and remember which is which.
      • layer8 2y ago
        Usually you settle on one or two “go to” functions, if you don’t write your own wrapper function anyway. Given the subtleties of their semantics, fully descriptive names also seem unachievable. But really, familiarity comes with repeated exposure. If you use these every day, you’ll learn rather quickly.
        • oersted 2y ago
          It's a good point. To be fair, any system that lasts as long as C has will have legacy cruft that you need to learn to step around and it's hard to get rid of. Relative to other standards, C has been remarkably disciplined at keeping things clean.
  • akira2501 2y ago
    > like their overly concise naming schemes don’t they One of the common features of "modern" languages that I can't comprehend is the love of single character sigils that completely change the meaning of a line of code or perhaps the entire enclosing function. > I guess “real programmers” memorize libc down to every detail Or, we just use 'man' and the massive 'section 3' of that system. A feature that no other language has managed to correctly replicate.
• adrian_b 2y ago
  Yes, but that is an internal function of the Linux kernel. It is available in user programs only if you define it yourself, e.g. by using memccpy.