7 ms·

It's too bad that many of the string handling functions in the C standard library are ticking time bombs. I like the approach taken in e.g. git which converts p

It's too bad that many of the string handling functions in the C standard library are ticking time bombs. I like the approach taken in e.g. git which converts problematic function calls into compile errors https://github.com/git/git/blob/master/banned.h https://github.com/git/git/blob/master/banned.h

Someone1234 5y ago
I like it too, but then you're going down the uncanny valley of: - The project is new, in which case you can easily/safely ban functions, but then why are you starting a new C project in 2021? - The project already exists, and now you need to refactor out all the compile-time errors in order to move forward (time-consuming). Keep in mind the first is a real question that should be answered. If your goal is to avoid undefined behavior/potential security headaches, then C should be entered into after careful consideration of cost/benefits. There are better alternatives for some projects but not others YMMV.
- hdjjhhvvhga 5y ago
  Both cases are real. If you start a new project in C, it means you have a very good reason - and hopefully a strategy of dealing with strings and other problematic issues. If you need to deal with an older codebase, the all-or-nothing approach might not be appropriate - incremental improvements might be a better option. Yes, you will have more problems to deal with initially, but with time the situation will get better.
  - ncmncm 5y ago
    > If you start a new project in C, it means you have a very good reason That does not follow. If you do it, you ought to have a good reason, but very probably don't. Any reason you thought you had, if you had any at all, argues for C++ instead, because it works anywhere C does, and enables you to choose to use modern methods that are not inherently error-prone. Whether you do choose to use modern methods, in any non-C language you end up using, is a whole other matter. But at least you can.
    - tsimionescu 5y ago
      There are still platforms with C compilers but no (or very bad) C++ compilers. It's much easier to write a decent C compiler than a C++ one.
      - gnubison 5y ago
        Yeah. If you want your code to “just work” on stuff like the BSDs, then C (or an interpreter written in C) is still your best bet.
      - ncmncm 5y ago
        The set of such platforms that one might start a new project for is very limited. Maybe, flight computer in a Boeing 737 variant? Betting that has no C compiler. 8051? The BSDs have supported C++ user-space programs for long enough that "just working" should be well within range. A new project involving a BSD or Linux kernel subsystem, or PostgreSQL or SQLite component, is a plausible interpretation, where C++ is actually forbidden for wholly non-technical reasons.
- tick_tock_tick 5y ago
  > The project is new, in which case you can safely ban functions, but then why are you starting a new C project in 2021? Interoperability? A tons of chips have a single C compiler forked from an old version of GCC without even full C99 support and that's it. Good luck getting anything else running on that hardware.
  - Someone1234 5y ago
    That's why you should evaluate the cost/benefit, like I said. > If your goal is to avoid undefined behavior/potential security headaches, then C should be entered into after careful consideration of cost/benefits. There are better alternatives for some projects but not others YMMV.
  - staticassertion 5y ago
    Yep, for the 0.0001% of developers who target arcane architectures C is still pretty much it.
- jonathrg 5y ago
  The ban can be rolled out gradually by not including banned.h everywhere.
  - Someone1234 5y ago
    But then you're undermining your own hard compile time check, wherein specific files or areas of the project could fall through the cracks and continue to used supposedly "banned" functions. I'd argue doing it globally but as warning would be a better alternative than doing it file by file.
    - jonathrg 5y ago
      A warning would be nice, is there a way to implement that without changing the compiler though?
      - shakna 5y ago
        Something along these lines should work, for at least both of GCC and Clang: extern void banned() __attribute__((deprecated("This function is problematic"))); #define strcpy(...) strcpy(__VA_ARGS__); banned; Which would output something along the lines of: test.c:11:3: warning: 'banned' is deprecated: This function is problematic [-Wdeprecated-declarations] strcpy(x, y);
      - yaur 5y ago
        MSVC does this, or at least did the last time I had to compile C code for windows. You should be able to do it with the preprocessor if you wanted to.
- yaur 5y ago
  We use C because significant parts of our platform are GStreamer plugins… so C. Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO.
  - tialaramex 5y ago
    You can have reasonable C FFI from several other languages. Notably in this context Rust. Of course if your code is just a thin layer of glue it's not worth it, you'd spend all your time getting into and out of the FFI. But if you write a non-trivial amount of code that actually does something because it isn't just a glue layer, C might actually not be the obvious choice after all. In the particular case of Rust, somebody else apparently already did this work (not tested, and thus not vouched for): https://crates.io/crates/gstreamer https://crates.io/crates/gstreamer
  - ncmncm 5y ago
    GStreamer plugins do not in any way dictate C. C++ works fine. As does Zig; and even Rust, with some annoyance.
  - pcwalton 5y ago
    > Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO. GStreamer is routinely exposed to hostile content in non-sandboxed contexts, such as your traditional Linux desktop; it even works as a browser plugin! Among projects you might want to write in C, GStreamer strikes me as one of the least reasonable. If GStreamer were more widely deployed on phones, it'd be prime attack surface for e.g. regimes attempting to surveil journalists.
    - tedunangst 5y ago
      "Yeah, but it's not that bad, because like, you can always choose not install the gstreamer-plugins-ugly package."
  - nemothekid 5y ago
    >We use C because significant parts of our platform are GStreamer plugins… so C. Ehh..., we have written and deployed gstreamer plugins for a proprietary project at $dayjob which was written in Rust. In the case of gstreamer, they have a plethora of examples for their Rust bindings (I think it's also officially supported).
- matheusmoreira 5y ago
  > why are you starting a new C project in 2021? Why not?
  - speedgoose 5y ago
    It's unsafe.
    - x4e 5y ago
      And what is safe? C has well defined, tested, and documented specifications which layout exactly how to use C safely. Languages like Rust are more safe but nothing is just safe. If you are an inexperienced developer it is still very easy to write insecure code in Rust. Sure, moving to safer languages is good. But it is impossible to rule out the use of a language so established that every major operating system is written in it. It is practically impossible to not use C - safe languages are normally bootstrapped by it and eventually your “safe” code will run in an environment programmed in C.
      - speedgoose 5y ago
        I agree that nothing is fully safe and any developer will alway introduce security vulnerabilities eventually, but history has proven than C is unsafe and generations of very competent developers wrote unsafe C despite documentation to write C safely.
    - matheusmoreira 5y ago
      It's pretty fun though. Despite all the problems, I just don't enjoy programming in other languages as much as I enjoy writing C. I've tried C++, Rust, Go, Zig, Javascript, Ruby, Python, Lisp, Lua... I just don't feel as free as I do while writing C.
- karottenreibe 5y ago
  > - The project already exists, and now you need to refactor out all the compile-time errors in order to move forward (time-consuming). Use a static analysis tool with proper, non-brittle tracking of new vs old findings (including proper move and copy file tracking) and forbid new findings, e.g. by preventing offending code from being merged to master with tools like Gitlab, Bitbucket, what have you. Works very well in practice. Bonus points if the tool can also tell you when you modified a function and didn't clean up the old findings in there. Then you can really enforce incremental improvement. Disclaimer: I work on Teamscale (https://teamscale.com https://teamscale.com), which does all that.
- pjmlp 5y ago
  One reason would be because you heard about Azure Sphere, their security marketing, and the 7 properties of highly secure platforms, so you order a devkit. Then when you open the box you discover that despite all the security talk, the only way to officially program the Azure Sphere is with a C SDK.
teknopurge 5y ago
Honestly not trolling - I disagree with the "ticking time bombs" comment. If you feel that way the devs should be using Rust. C is a sharp knife with no handle; this is it's purpose as a language and tool. cc: theo@openbsd.org
- jonathrg 5y ago
  These are just simple API design issues in the standard library, nothing to do with the language itself.
- tialaramex 5y ago
  > the devs should be using Rust. Yes, they should. Or several other things depending on what exactly they need. > C is a sharp knife with no handle; this is it's purpose as a language and tool. Help me out here HN resident survivalists, carpenters, maybe circus knife throwers. What is the "purpose" of a "sharp knife with no handle" exactly? How often have you thought, "Man, it'd be so much easier to gather firewood, carve decorations or score a bullseye if only the blade would sink into my own flesh while I was using it because it doesn't have a handle" ? Historically the argument was, "We're using C because alternatives like Java or Python or whatever aren't fast enough or capable enough". OK. But, somewhere in the last few years it moved to, "We're using C because alternatives aren't dangerous enough" and that's crazy.
  - teknopurge 5y ago
    BYOH - Bring You Own Handle The purpose is not to assume what the developer wants, but provide access to all the resources(and manipulation) they need. If you need guardrails there are 10s of languages designed for specific purposes.
    - hiccuphippo 5y ago
      FWIW, Zig is as sharp as C but with a handle.
      - 5y ago
pjmlp 5y ago
I would rather use C++, however if I really must write C, then a string handling library like the SDS from Redis project is a must. https://github.com/antirez/sds https://github.com/antirez/sds Naturally turning on all security features of the C compiler being used, warnings, warnings as errors, static analysers, FORTIFY like libraries, the whole package. And like almost everyone else, I end up having my occasional segfault regardless of the amount of precautions taken, because I am not elite enough.

Someone1234 5y ago

I like it too, but then you're going down the uncanny valley of: - The project is new, in which case you can easily/safely ban functions, but then why are you starting a new C project in 2021? - The project already exists, and now you need to refactor out all the compile-time errors in order to move forward (time-consuming). Keep in mind the first is a real question that should be answered. If your goal is to avoid undefined behavior/potential security headaches, then C should be entered into after careful consideration of cost/benefits. There are better alternatives for some projects but not others YMMV.

hdjjhhvvhga 5y ago
Both cases are real. If you start a new project in C, it means you have a very good reason - and hopefully a strategy of dealing with strings and other problematic issues. If you need to deal with an older codebase, the all-or-nothing approach might not be appropriate - incremental improvements might be a better option. Yes, you will have more problems to deal with initially, but with time the situation will get better.
- ncmncm 5y ago
  > If you start a new project in C, it means you have a very good reason That does not follow. If you do it, you ought to have a good reason, but very probably don't. Any reason you thought you had, if you had any at all, argues for C++ instead, because it works anywhere C does, and enables you to choose to use modern methods that are not inherently error-prone. Whether you do choose to use modern methods, in any non-C language you end up using, is a whole other matter. But at least you can.
  - tsimionescu 5y ago
    There are still platforms with C compilers but no (or very bad) C++ compilers. It's much easier to write a decent C compiler than a C++ one.
    - gnubison 5y ago
      Yeah. If you want your code to “just work” on stuff like the BSDs, then C (or an interpreter written in C) is still your best bet.
    - ncmncm 5y ago
      The set of such platforms that one might start a new project for is very limited. Maybe, flight computer in a Boeing 737 variant? Betting that has no C compiler. 8051? The BSDs have supported C++ user-space programs for long enough that "just working" should be well within range. A new project involving a BSD or Linux kernel subsystem, or PostgreSQL or SQLite component, is a plausible interpretation, where C++ is actually forbidden for wholly non-technical reasons.
tick_tock_tick 5y ago
> The project is new, in which case you can safely ban functions, but then why are you starting a new C project in 2021? Interoperability? A tons of chips have a single C compiler forked from an old version of GCC without even full C99 support and that's it. Good luck getting anything else running on that hardware.
- Someone1234 5y ago
  That's why you should evaluate the cost/benefit, like I said. > If your goal is to avoid undefined behavior/potential security headaches, then C should be entered into after careful consideration of cost/benefits. There are better alternatives for some projects but not others YMMV.
- staticassertion 5y ago
  Yep, for the 0.0001% of developers who target arcane architectures C is still pretty much it.
jonathrg 5y ago
The ban can be rolled out gradually by not including banned.h everywhere.
- Someone1234 5y ago
  But then you're undermining your own hard compile time check, wherein specific files or areas of the project could fall through the cracks and continue to used supposedly "banned" functions. I'd argue doing it globally but as warning would be a better alternative than doing it file by file.
  - jonathrg 5y ago
    A warning would be nice, is there a way to implement that without changing the compiler though?
    - shakna 5y ago
      Something along these lines should work, for at least both of GCC and Clang: extern void banned() __attribute__((deprecated("This function is problematic"))); #define strcpy(...) strcpy(__VA_ARGS__); banned; Which would output something along the lines of: test.c:11:3: warning: 'banned' is deprecated: This function is problematic [-Wdeprecated-declarations] strcpy(x, y);
    - yaur 5y ago
      MSVC does this, or at least did the last time I had to compile C code for windows. You should be able to do it with the preprocessor if you wanted to.
yaur 5y ago
We use C because significant parts of our platform are GStreamer plugins… so C. Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO.
- tialaramex 5y ago
  You can have reasonable C FFI from several other languages. Notably in this context Rust. Of course if your code is just a thin layer of glue it's not worth it, you'd spend all your time getting into and out of the FFI. But if you write a non-trivial amount of code that actually does something because it isn't just a glue layer, C might actually not be the obvious choice after all. In the particular case of Rust, somebody else apparently already did this work (not tested, and thus not vouched for): https://crates.io/crates/gstreamer https://crates.io/crates/gstreamer
- ncmncm 5y ago
  GStreamer plugins do not in any way dictate C. C++ works fine. As does Zig; and even Rust, with some annoyance.
- pcwalton 5y ago
  > Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO. GStreamer is routinely exposed to hostile content in non-sandboxed contexts, such as your traditional Linux desktop; it even works as a browser plugin! Among projects you might want to write in C, GStreamer strikes me as one of the least reasonable. If GStreamer were more widely deployed on phones, it'd be prime attack surface for e.g. regimes attempting to surveil journalists.
  - tedunangst 5y ago
    "Yeah, but it's not that bad, because like, you can always choose not install the gstreamer-plugins-ugly package."
- nemothekid 5y ago
  >We use C because significant parts of our platform are GStreamer plugins… so C. Ehh..., we have written and deployed gstreamer plugins for a proprietary project at $dayjob which was written in Rust. In the case of gstreamer, they have a plethora of examples for their Rust bindings (I think it's also officially supported).
matheusmoreira 5y ago
> why are you starting a new C project in 2021? Why not?
- speedgoose 5y ago
  It's unsafe.
  - x4e 5y ago
    And what is safe? C has well defined, tested, and documented specifications which layout exactly how to use C safely. Languages like Rust are more safe but nothing is just safe. If you are an inexperienced developer it is still very easy to write insecure code in Rust. Sure, moving to safer languages is good. But it is impossible to rule out the use of a language so established that every major operating system is written in it. It is practically impossible to not use C - safe languages are normally bootstrapped by it and eventually your “safe” code will run in an environment programmed in C.
    - speedgoose 5y ago
      I agree that nothing is fully safe and any developer will alway introduce security vulnerabilities eventually, but history has proven than C is unsafe and generations of very competent developers wrote unsafe C despite documentation to write C safely.
  - matheusmoreira 5y ago
    It's pretty fun though. Despite all the problems, I just don't enjoy programming in other languages as much as I enjoy writing C. I've tried C++, Rust, Go, Zig, Javascript, Ruby, Python, Lisp, Lua... I just don't feel as free as I do while writing C.
karottenreibe 5y ago
> - The project already exists, and now you need to refactor out all the compile-time errors in order to move forward (time-consuming). Use a static analysis tool with proper, non-brittle tracking of new vs old findings (including proper move and copy file tracking) and forbid new findings, e.g. by preventing offending code from being merged to master with tools like Gitlab, Bitbucket, what have you. Works very well in practice. Bonus points if the tool can also tell you when you modified a function and didn't clean up the old findings in there. Then you can really enforce incremental improvement. Disclaimer: I work on Teamscale (https://teamscale.com https://teamscale.com), which does all that.
pjmlp 5y ago
One reason would be because you heard about Azure Sphere, their security marketing, and the 7 properties of highly secure platforms, so you order a devkit. Then when you open the box you discover that despite all the security talk, the only way to officially program the Azure Sphere is with a C SDK.

teknopurge 5y ago

Honestly not trolling - I disagree with the "ticking time bombs" comment. If you feel that way the devs should be using Rust. C is a sharp knife with no handle; this is it's purpose as a language and tool. cc: theo@openbsd.org

jonathrg 5y ago
These are just simple API design issues in the standard library, nothing to do with the language itself.
tialaramex 5y ago
> the devs should be using Rust. Yes, they should. Or several other things depending on what exactly they need. > C is a sharp knife with no handle; this is it's purpose as a language and tool. Help me out here HN resident survivalists, carpenters, maybe circus knife throwers. What is the "purpose" of a "sharp knife with no handle" exactly? How often have you thought, "Man, it'd be so much easier to gather firewood, carve decorations or score a bullseye if only the blade would sink into my own flesh while I was using it because it doesn't have a handle" ? Historically the argument was, "We're using C because alternatives like Java or Python or whatever aren't fast enough or capable enough". OK. But, somewhere in the last few years it moved to, "We're using C because alternatives aren't dangerous enough" and that's crazy.
- teknopurge 5y ago
  BYOH - Bring You Own Handle The purpose is not to assume what the developer wants, but provide access to all the resources(and manipulation) they need. If you need guardrails there are 10s of languages designed for specific purposes.
  - hiccuphippo 5y ago
    FWIW, Zig is as sharp as C but with a handle.
    - 5y ago

pjmlp 5y ago

I would rather use C++, however if I really must write C, then a string handling library like the SDS from Redis project is a must. https://github.com/antirez/sds https://github.com/antirez/sds Naturally turning on all security features of the C compiler being used, warnings, warnings as errors, static analysers, FORTIFY like libraries, the whole package. And like almost everyone else, I end up having my occasional segfault regardless of the amount of precautions taken, because I am not elite enough.