4 ms·

> If I write some code, I’m realistically the expert. Ha, disagree. This is overly general and reductionist. See, I know the C strcpy() function is a bad idea

> If I write some code, I’m realistically the expert. Ha, disagree. This is overly general and reductionist. See, I know the C strcpy() function is a bad idea. In this I know more than Ken Thompson or whatever Unix God did at the time he wrote it. I also know more than everybody who wrote (at the time they wrote) every other library that's on my computer that uses strcpy(). Why the fuck is this still in my system? Division of labor accumulates bad ideas along with good ones.

mwcampbell 5y ago
> Division of labor accumulates bad ideas along with good ones. Agreed. To take an example from my area of specialization, accessibility, both Windows accessibility APIs (yes, as is often the case with Windows, there's more than one) have serious design flaws IMO. But they still allow disabled people to do many things we would otherwise be unable to do. I worry about what will happen if programmers truly follow your proposal from another subthread: "build/reuse less. Do without." In this case, doing without would make computers much less useful for many people, and possibly erect new barriers to employment, education, and just living one's life.
spc476 5y ago
It's bad now. It might not have been bad when it was originally written. Back when Unix was first being developed, you had machines with 64K or 128K of RAM, which is not much, and because of that, software was much simpler, and such design compromises could be kept in mind. And when C was standardized in 1989, it might have been a bad idea at that time, but the standards committee didn't want to obsolete all the existing code (a major concern at the time). But by all means, get a time machine and plead your case. As an example of coding for size, I recently wrote a copy of strcpy() with similar semantics. I had to, because of constraints on memory. I wrote an MC6809 (an 8-bit CPU) disassembler in MC6809 assembly code, and the prime consideration was code size. Strings ending with a NUL byte? My GOD! that will waste 80 bytes! Waste a byte on size? That's another 80 (or 160 if you insist on 16 bits for size) bytes wasted! Instead, since all the text is ASCII, set the high bit on the last character. That more than makes up for the bit of oddness in my implementation of strcpy() to deal with the last byte, and helped contribute to the code being 2K in size.
- akkartik 5y ago
  What makes strcpy() a better compromise than strncpy() or strlcpy() with 64K or 128K of RAM?
  - spc476 5y ago
    strncpy() is for a different context, and it won't necessarily NUL terminate the destination [1]. It's not a compromise for strcpy(). strlcopy() will NUL terminate the destination, but it first appeared in 1998, nine years after C was standardized, so again, time machine etc. Should Ken Thompson & co. included strlcpy()? It's an argument one could make, but I'm sure they didn't see a need for it for what they were doing. Oversight? Not even thinking about it? Yes, but I don't blame them for failing to see the future. Should Intel not do speculative execution because it lead to Specter? Now, assuming strlcpy() existed in the 70s---is that just as efficient as strcpy()? Should strcpy() have always included the size? Again, I think it comes down to the context of the times. Having worked on systems with 64K (or less! My first computer only had 16K of RAM), and with the experience of hindsight, the idea of implementing malloc() is overkill on such a system (and maybe even 128K systems), but I won't say people were stupid for doing so at the time. [1] I think strcnpy() was there to handle the original Unix filesystem, where a directory was nothing more than a file of 16-byte entries---14 bytes for the filename, and two bytes for the indode.
    - akkartik 5y ago
      > Should Ken Thompson & co. included strlcpy()? I'm getting a little impatient with all this argument in circles. The point is not what someone should have done with hindsight. The point of this little sub-thread is that saying the author is always the expert is oxymoronic. Expertise is often multifaceted and distributed. The larger point is also that it should be possible to get rid of things once hindsight has found them wanting.
      - dpark 5y ago
        > The point of this little sub-thread is that saying the author is always the expert is oxymoronic. Writing the code makes me the expert in that code. Meaning how it works. Why it was built the way it was. How it was intended to be extended. Yeah, it might be shitty code and maybe someone with more domain or even just general expertise would be able to do better. But if I write the code, I’m still the expert in that specific code. Someone else can of course roll in and become and expert in that code, too. Expertise in my code is not a bounded resource. If you took my comment to mean that writing the code makes me the expert on all possible implementations or choices for the solution, or that I am best qualified to decide what the best solution is, I must have communicated poorly. (Also, this is pedantic, but that’s not what oxymoronic means.)
dpark 5y ago
What you’re actually saying is that you have the benefit of hindsight. That in no way makes you more on an expert than Ken Thompson who also has the benefit of hindsight. I would guess that literally thousands of people have implemented an equivalent to strcpy with exactly the same issues (and likely more). Reimplemention does not imply a better implementation. Decades of experience using strcpy is what taught us it’s a bad idea, not reimplementing it a thousand times.
- akkartik 5y ago
  Maybe it took you decades. One decade sufficed for most of the world. This is starting to feel like a pissing contest. Go write your software thinking you know more than your users. Me, I constantly need to talk to mine. They're often more expert on the domain than me.
  - dpark 5y ago
    > This is starting to feel like a pissing contest. Is there some reason it suddenly went from us discussing a difference of opinion to hostility? I have no idea what this is about. > Go write your software thinking you know more than your users. That’s a strange nonsequitur. End customers don’t generally tell me how to craft software. When I work with customers, it’s to understand their domain and their problems, not mine. Again, not sure where this hostility is coming from.
    - akkartik 5y ago
      Perhaps I'm coming down with something. I'm uninterested in the sub-thread past https://news.ycombinator.com/item?id=30019146#30042174 https://news.ycombinator.com/item?id=30019146#30042174. It feels like willful misinterpretation, like you forgot what I said 2 exchanges ago when you respond to any single comment. I've said my piece in a bunch of different ways, over ten years and again ten times to you. Perhaps this is as close as we're going to get to mutual understanding, if you think after all this that I'm trying to one-up Ken Thompson or something. I think you're using words like "expert" and "strictly worse" way too bluntly. What's better for the author is often not what's better for the user.

mwcampbell 5y ago

> Division of labor accumulates bad ideas along with good ones. Agreed. To take an example from my area of specialization, accessibility, both Windows accessibility APIs (yes, as is often the case with Windows, there's more than one) have serious design flaws IMO. But they still allow disabled people to do many things we would otherwise be unable to do. I worry about what will happen if programmers truly follow your proposal from another subthread: "build/reuse less. Do without." In this case, doing without would make computers much less useful for many people, and possibly erect new barriers to employment, education, and just living one's life.

spc476 5y ago

It's bad now. It might not have been bad when it was originally written. Back when Unix was first being developed, you had machines with 64K or 128K of RAM, which is not much, and because of that, software was much simpler, and such design compromises could be kept in mind. And when C was standardized in 1989, it might have been a bad idea at that time, but the standards committee didn't want to obsolete all the existing code (a major concern at the time). But by all means, get a time machine and plead your case. As an example of coding for size, I recently wrote a copy of strcpy() with similar semantics. I had to, because of constraints on memory. I wrote an MC6809 (an 8-bit CPU) disassembler in MC6809 assembly code, and the prime consideration was code size. Strings ending with a NUL byte? My GOD! that will waste 80 bytes! Waste a byte on size? That's another 80 (or 160 if you insist on 16 bits for size) bytes wasted! Instead, since all the text is ASCII, set the high bit on the last character. That more than makes up for the bit of oddness in my implementation of strcpy() to deal with the last byte, and helped contribute to the code being 2K in size.

akkartik 5y ago
What makes strcpy() a better compromise than strncpy() or strlcpy() with 64K or 128K of RAM?
- spc476 5y ago
  strncpy() is for a different context, and it won't necessarily NUL terminate the destination [1]. It's not a compromise for strcpy(). strlcopy() will NUL terminate the destination, but it first appeared in 1998, nine years after C was standardized, so again, time machine etc. Should Ken Thompson & co. included strlcpy()? It's an argument one could make, but I'm sure they didn't see a need for it for what they were doing. Oversight? Not even thinking about it? Yes, but I don't blame them for failing to see the future. Should Intel not do speculative execution because it lead to Specter? Now, assuming strlcpy() existed in the 70s---is that just as efficient as strcpy()? Should strcpy() have always included the size? Again, I think it comes down to the context of the times. Having worked on systems with 64K (or less! My first computer only had 16K of RAM), and with the experience of hindsight, the idea of implementing malloc() is overkill on such a system (and maybe even 128K systems), but I won't say people were stupid for doing so at the time. [1] I think strcnpy() was there to handle the original Unix filesystem, where a directory was nothing more than a file of 16-byte entries---14 bytes for the filename, and two bytes for the indode.
  - akkartik 5y ago
    > Should Ken Thompson & co. included strlcpy()? I'm getting a little impatient with all this argument in circles. The point is not what someone should have done with hindsight. The point of this little sub-thread is that saying the author is always the expert is oxymoronic. Expertise is often multifaceted and distributed. The larger point is also that it should be possible to get rid of things once hindsight has found them wanting.
    - dpark 5y ago
      > The point of this little sub-thread is that saying the author is always the expert is oxymoronic. Writing the code makes me the expert in that code. Meaning how it works. Why it was built the way it was. How it was intended to be extended. Yeah, it might be shitty code and maybe someone with more domain or even just general expertise would be able to do better. But if I write the code, I’m still the expert in that specific code. Someone else can of course roll in and become and expert in that code, too. Expertise in my code is not a bounded resource. If you took my comment to mean that writing the code makes me the expert on all possible implementations or choices for the solution, or that I am best qualified to decide what the best solution is, I must have communicated poorly. (Also, this is pedantic, but that’s not what oxymoronic means.)

dpark 5y ago

What you’re actually saying is that you have the benefit of hindsight. That in no way makes you more on an expert than Ken Thompson who also has the benefit of hindsight. I would guess that literally thousands of people have implemented an equivalent to strcpy with exactly the same issues (and likely more). Reimplemention does not imply a better implementation. Decades of experience using strcpy is what taught us it’s a bad idea, not reimplementing it a thousand times.

akkartik 5y ago
Maybe it took you decades. One decade sufficed for most of the world. This is starting to feel like a pissing contest. Go write your software thinking you know more than your users. Me, I constantly need to talk to mine. They're often more expert on the domain than me.
- dpark 5y ago
  > This is starting to feel like a pissing contest. Is there some reason it suddenly went from us discussing a difference of opinion to hostility? I have no idea what this is about. > Go write your software thinking you know more than your users. That’s a strange nonsequitur. End customers don’t generally tell me how to craft software. When I work with customers, it’s to understand their domain and their problems, not mine. Again, not sure where this hostility is coming from.
  - akkartik 5y ago
    Perhaps I'm coming down with something. I'm uninterested in the sub-thread past https://news.ycombinator.com/item?id=30019146#30042174 https://news.ycombinator.com/item?id=30019146#30042174. It feels like willful misinterpretation, like you forgot what I said 2 exchanges ago when you respond to any single comment. I've said my piece in a bunch of different ways, over ten years and again ten times to you. Perhaps this is as close as we're going to get to mutual understanding, if you think after all this that I'm trying to one-up Ken Thompson or something. I think you're using words like "expert" and "strictly worse" way too bluntly. What's better for the author is often not what's better for the user.