4 ms·

The problem with C and buffer overflows isn't that you can't guard against them, or that there is no existing, reusable code to do so — it's that none of this f

The problem with C and buffer overflows isn't that you can't guard against them, or that there is no existing, reusable code to do so — it's that none of this functionality is standardized. Adding another one to the existing 41383 ways of doing this is in fact the exact opposite of what's needed. Ideally C needs one way of doing this, and that would be described in the standard. But that's not how C "rolls", and we'll never get that. So I guess we now have 41384 ways to do buffer overflow guards.

ActorNightly 3y ago
There is value in actually understanding what someone is doing in regards to protecting against buffer overflows, instead of relying on well established patterns.
- hinkley 3y ago
  Not when I’m trying to orchestrate third party libraries.
6D794163636F756 3y ago
C never has just one way to do something. myArr[5] == 5[myArr] == (insert pointer arithmetic that I won't write here without a compiler check). I think that part of C's beauty is that it gives you freedom. Freedom to shoot yourself in the foot, freedom to write hyper efficient code, and freedom to choose another tool. I agree that this will never be implemented as a standard, but I think that's a good thing. Higher level languages push against their boundaries non stop. Java has libraries and frameworks that fundamentally change the syntax and functionality of the language. C knows what it is. If you want something that it can't do it promises that you can either build it yourself or switch to a different tool. All of this to say, C has a single suggested way of doing this: using a different language. That's part of why we built them
- adastra22 3y ago
  Those are syntactic sugar for the same thing though. Array[5] is just shorthand for *(Array + 5), which is why 5[Array] also works (because addition is commutative). Note that C does have strong conventions, such as that strings are terminated by a zero byte. Nothing in the language demands that, it’s just a convention! C could adopt better conventions.
  - astrobe_ 3y ago
    > Note that C does have strong conventions, such as that strings are terminated by a zero byte Stated the same on HN earlier, but someone pointed out that literal strings are ASCIIZ.
    - adastra22 3y ago
      One common trick in safer C libraries is to encode the length of the string one word prior to the beginning of the string. So "hello world" in memory would be 11 'h' 'e' 'l' 'l' 'o' ' ' 'w' 'o' 'r' 'l' 'd' '\0' ptr ^ C could be upgraded to do this in future versions, without too much backwards incompatibility.
      - JohnFen 3y ago
        > C could be upgraded to do this in future versions, without too much backwards incompatibility. But I'd hope that doing that would always be optional. There are numerous situations where that would seriously get in the way.
        ranger_danger 3y ago
        Could you mention one of them?
        JohnFen 3y ago
        Sure. For instance, there are times when you need to pack strings tightly together. Adding an extra byte or two before the start of the string would get in the way. You could work around it in many cases, but it makes the code uglier and harder to understand/maintain. One of the things that makes C particularly suitable for certain sorts of tasks is that it's mostly WYSIWYG when it comes to the relationship between data structures and the actual memory layout. Having "hidden" things like a length value before the string steps on that.
- shrimp_emoji 3y ago
  Checked arithmetic has been implemented in the standard with `ckdint.h`, so give it 50 more years!
nix0n 3y ago
> existing, reusable code to do so Is there a library that you recommend for this?
JohnFen 3y ago
> Ideally C needs one way of doing this, and that would be described in the standard. I'm really glad that C doesn't do this, personally. It would reduce one of the main advantages of the language.

ActorNightly 3y ago

There is value in actually understanding what someone is doing in regards to protecting against buffer overflows, instead of relying on well established patterns.

hinkley 3y ago
Not when I’m trying to orchestrate third party libraries.

6D794163636F756 3y ago

C never has just one way to do something. myArr[5] == 5[myArr] == (insert pointer arithmetic that I won't write here without a compiler check). I think that part of C's beauty is that it gives you freedom. Freedom to shoot yourself in the foot, freedom to write hyper efficient code, and freedom to choose another tool. I agree that this will never be implemented as a standard, but I think that's a good thing. Higher level languages push against their boundaries non stop. Java has libraries and frameworks that fundamentally change the syntax and functionality of the language. C knows what it is. If you want something that it can't do it promises that you can either build it yourself or switch to a different tool. All of this to say, C has a single suggested way of doing this: using a different language. That's part of why we built them

adastra22 3y ago
Those are syntactic sugar for the same thing though. Array[5] is just shorthand for *(Array + 5), which is why 5[Array] also works (because addition is commutative). Note that C does have strong conventions, such as that strings are terminated by a zero byte. Nothing in the language demands that, it’s just a convention! C could adopt better conventions.
- astrobe_ 3y ago
  > Note that C does have strong conventions, such as that strings are terminated by a zero byte Stated the same on HN earlier, but someone pointed out that literal strings are ASCIIZ.
  - adastra22 3y ago
    One common trick in safer C libraries is to encode the length of the string one word prior to the beginning of the string. So "hello world" in memory would be 11 'h' 'e' 'l' 'l' 'o' ' ' 'w' 'o' 'r' 'l' 'd' '\0' ptr ^ C could be upgraded to do this in future versions, without too much backwards incompatibility.
    - JohnFen 3y ago
      > C could be upgraded to do this in future versions, without too much backwards incompatibility. But I'd hope that doing that would always be optional. There are numerous situations where that would seriously get in the way.
      - ranger_danger 3y ago
        Could you mention one of them?
        JohnFen 3y ago
        Sure. For instance, there are times when you need to pack strings tightly together. Adding an extra byte or two before the start of the string would get in the way. You could work around it in many cases, but it makes the code uglier and harder to understand/maintain. One of the things that makes C particularly suitable for certain sorts of tasks is that it's mostly WYSIWYG when it comes to the relationship between data structures and the actual memory layout. Having "hidden" things like a length value before the string steps on that.
shrimp_emoji 3y ago
Checked arithmetic has been implemented in the standard with `ckdint.h`, so give it 50 more years!

nix0n 3y ago

> existing, reusable code to do so Is there a library that you recommend for this?

JohnFen 3y ago

> Ideally C needs one way of doing this, and that would be described in the standard. I'm really glad that C doesn't do this, personally. It would reduce one of the main advantages of the language.