4 ms·

In C/C++ land you control what third party libraries you use / don't use and you don't use the ones that behave badly

by verall 3y ago

vacuity 3y ago
Imagine if programmers did that with memory safety. "Hey, is the program interfacing with any C/C++ libraries that aren't rigorously sanitized and fuzzed for memory safety? If so, throw them out." Yes, theoretically you can control these things. In practice, most people aren't going to and the few that try may have to expend a lot of effort.
- Ferret7446 3y ago
  I thought that was in fact standard practice in any sort of serious software engineering. Do you not audit your dependencies? I mean, running ASan is basically free.
  - vacuity 3y ago
    Well, it hasn't stopped memory safety bugs from being a thing, that's for sure.
- verall 3y ago
  You're free to spend your free time/money rewriting mountains of legacy C/C++ code in memory safe languages to use in your projects. Good luck.
  - vacuity 3y ago
    It's like you didn't read my comment. Of course I'm free to spend my time doing that, but significant memory safety or thread safety hazards can't just be waved away because "you can vet your dependencies". For smaller projects, perhaps, but it's not feasible in general. This can be a source of actual exploits that cost millions of dollars or leak personal information. Footguns don't just become not a problem because they don't affect you. Whether setenv's lack of thread safety matters in practice and whether backwards compatibility hinders a fix are both factors to consider, but your reasoning is just absurd. I guess everyone who doesn't rigorously vet their C/C++ dependencies up to and including libc is just a bad programmer.
    - verall 3y ago
      I did read your comment, but I guess I didn't fully understand it? I'm not waving away memory safety or thread safety hazards, that's just the state of things. There's mountains of legacy C and C++ code that you can use. Or you can not use it. It's inexpensive to use (you don't have to write it), but not free - you may have to chase a wild bug down now and then. I guess the part I don't understand, is that you said "Imagine if we applied this logic to memory safety", so I imagined it, and I imagined it would mean a lot of code would have to be rewritten. Or maybe, you meant something like "it's absurd to vet your dependencies for setenv issues when noone vets dependencies for memory safety", which still doesn't make sense to me. The point I was trying to make, is that C/C++ developers generally _do_ vet (and vendor) their dependencies, while developers in other ecosystems don't as much. go is big enough that if they want to provide a library call to setenv/getenv and _not_ make their users read the man pages, maybe they should add a lock or provide their own implementation. I still think GP saying basically "you can't control what your dependencies use" is kind of ridiculous, because you do control what dependencies you use, and you should probably fix or toss the ones crashing your program. > I guess everyone who doesn't rigorously vet their C/C++ dependencies up to and including libc is just a bad programmer. I'm not saying this at all. It's just your job to fix it, or to convince your manager it's not your fault it crashes. If you rely on other peoples code, eventually they will have a bug. It's inevitable.
      - vacuity 3y ago
        We mostly agree then, but I think the scale of enterprise software development in languages such as Go and Rust is such that telling people to vet their dependencies isn't a feasible solution. If the dependencies are free software, it may be fairly easy to fix the setenv bugs, but they might not be. Ideally, there should be action on the C side to make this less of a problem overall, instead of just for the people who have the time and energy to fix this locally. Not sure if that's feasible based on backwards compatibility, but that's a different problem.
        verall 3y ago
        Anyone can submit a patch on the C side to make this less of a problem, but if it's not a problem for most people on the C side, why wouldn't it get fixed in go or rust instead? The cycle goes: "it's hard to support a lot of platforms" -> "let's support a common interface" -> "posix sucks" -> "it's hard to support a lot of platforms" Changing posix means distributing your work among all of the platforms rather than adding your own implementations and confirming they work on everything. Not likely to get buy in unless something is causing problems for whoever is paying those platform developers, or libc maintainers.

In C/C++ land you control what third party libraries you use / don't use and you don't use the ones that behave badly

by verall 3y ago

In C/C++ land you control what third party libraries you use / don't use and you don't use the ones that behave badly

Imagine if programmers did that with memory safety. "Hey, is the program interfacing with any C/C++ libraries that aren't rigorously sanitized and fuzzed for memory safety? If so, throw them out." Yes, theoretically you can control these things. In practice, most people aren't going to and the few that try may have to expend a lot of effort.

Ferret7446 3y ago
I thought that was in fact standard practice in any sort of serious software engineering. Do you not audit your dependencies? I mean, running ASan is basically free.
- vacuity 3y ago
  Well, it hasn't stopped memory safety bugs from being a thing, that's for sure.
verall 3y ago
You're free to spend your free time/money rewriting mountains of legacy C/C++ code in memory safe languages to use in your projects. Good luck.
- vacuity 3y ago
  It's like you didn't read my comment. Of course I'm free to spend my time doing that, but significant memory safety or thread safety hazards can't just be waved away because "you can vet your dependencies". For smaller projects, perhaps, but it's not feasible in general. This can be a source of actual exploits that cost millions of dollars or leak personal information. Footguns don't just become not a problem because they don't affect you. Whether setenv's lack of thread safety matters in practice and whether backwards compatibility hinders a fix are both factors to consider, but your reasoning is just absurd. I guess everyone who doesn't rigorously vet their C/C++ dependencies up to and including libc is just a bad programmer.
  - verall 3y ago
    I did read your comment, but I guess I didn't fully understand it? I'm not waving away memory safety or thread safety hazards, that's just the state of things. There's mountains of legacy C and C++ code that you can use. Or you can not use it. It's inexpensive to use (you don't have to write it), but not free - you may have to chase a wild bug down now and then. I guess the part I don't understand, is that you said "Imagine if we applied this logic to memory safety", so I imagined it, and I imagined it would mean a lot of code would have to be rewritten. Or maybe, you meant something like "it's absurd to vet your dependencies for setenv issues when noone vets dependencies for memory safety", which still doesn't make sense to me. The point I was trying to make, is that C/C++ developers generally _do_ vet (and vendor) their dependencies, while developers in other ecosystems don't as much. go is big enough that if they want to provide a library call to setenv/getenv and _not_ make their users read the man pages, maybe they should add a lock or provide their own implementation. I still think GP saying basically "you can't control what your dependencies use" is kind of ridiculous, because you do control what dependencies you use, and you should probably fix or toss the ones crashing your program. > I guess everyone who doesn't rigorously vet their C/C++ dependencies up to and including libc is just a bad programmer. I'm not saying this at all. It's just your job to fix it, or to convince your manager it's not your fault it crashes. If you rely on other peoples code, eventually they will have a bug. It's inevitable.
    - vacuity 3y ago
      We mostly agree then, but I think the scale of enterprise software development in languages such as Go and Rust is such that telling people to vet their dependencies isn't a feasible solution. If the dependencies are free software, it may be fairly easy to fix the setenv bugs, but they might not be. Ideally, there should be action on the C side to make this less of a problem overall, instead of just for the people who have the time and energy to fix this locally. Not sure if that's feasible based on backwards compatibility, but that's a different problem.
      - verall 3y ago
        Anyone can submit a patch on the C side to make this less of a problem, but if it's not a problem for most people on the C side, why wouldn't it get fixed in go or rust instead? The cycle goes: "it's hard to support a lot of platforms" -> "let's support a common interface" -> "posix sucks" -> "it's hard to support a lot of platforms" Changing posix means distributing your work among all of the platforms rather than adding your own implementations and confirming they work on everything. Not likely to get buy in unless something is causing problems for whoever is paying those platform developers, or libc maintainers.