> 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.