> It wasn't meant that way. Rather, it's why I'm so concerned about buffer overflows. All the software we use here is either written in C, uses a C library, or is built on C. Most of the security advisories we've had to worry about were related to C's handling of strings.
Then I apologize!
I simply disagree; I think it has to do with the irresponsible handling of strings. If you'll note, that can easily include injection and quoting attacks as well.
> At compile time? Run time?
> Why shouldn't C be able to do something like this at compiler time? What problems will it cause?
I'm talking about compile time as well; it's a readability thing. When I do audits, I use ctags
to track the sizes of the accessors when checking for pointer escapes (off-by-one errors, etc). If I see this:
do { char *i; /* 50 lines later */ something-with-i } ...
do { int i; /* 50 lines later */ ...
then it's hard to tell what the type of "i" is by looking at it.
I personally use very short functions, but I frequently have to look at code like this. var
would work exactly in this way except I would have to follow the assignment to see what its type is.
Compilers can do amazing things, and the cost (as you've noted) isn't always in run-time cycles.
But as I said, you can try using var
right now with some macros. Try something like this:
#define var(x,y) typeof(y) x=y;
to see how you like it. It'll be easier to talk about what a good idea it is when you've tried it out in real code for a while.
I find it very difficult to follow, and it seems obvious to me that this would be a good way to hide complexities and costs from the programmer. Something that I think contributes to a lot of defects and security bugs in the first place.
> I realize this is a brush-off, but I think assembly or Forth is more suitable for a device that is so constrained.
I agree, most of the time. Unfortunately, I have customers afraid of forth...
> I think it makes a class of possible vulnerabilities a lot less likely. It can't prevent them. It won't do anything else about the myriad other possible problems you get with a low-level language. But it'll dramatically reduce a common class of problems.
Trading one kind of problem for another isn't really winning; if programmers learn that s[-1]
contains the length of a string, you'll start seeing code like this: fill_buffer(s,0,s[-1]);
and while fill_buffer
will certainly be able to check that length <= s[-1]
, it won't know that this is wrong.