[Info-vax] Whither VMS?

[Michael Kraemer]

Jordi Guillaumes i Pons schrieb:

> 
> Programmers are, some times, lazy. Specially when they work under 
> unrealistic schedules and not enough resources. 

I don't buy that. Errors of the kind below are not
due to lack of resources.

> You can find a lot of 
> things like this in production:
> 
> void someFunction(char *someString) {
>     char aBuffer[1024];
>     strcpy(aBuffer, someString);
>     doSomething(aBuffer);
> }

That's not a problem of null termination,
it's a problem of writing to an area you do not own.
This may happen in any language, i.e.
Assuming a fixed size of your data objects
because it would never ever been exceeded
(Y2K comes to mind).
In C, one would have used sth like
aBuffer = calloc( strlen(someString)+1, sizeof(*aBuffer) )

> 
> The problem is that in C you don't have tools (AFAIK) to catch time 
> bombs like this one in compilation time nor, probably, in test time. In 
> higher level languages (COBOL, PLI, even java) you can enable runtime 
> range checking, 

and it would be switched off for production release,
where most of the buffer oflos would surface.

> and in some cases, even compiletime verification (which 
> usually gives a WARNING). But not in C. 

That would be a compiler issue, not a language issue.

> You can have this code working 
> quietly for years... until a programmer writes something which calls 
> someFunction() with a 2048 bytes string. Or something who passes a 
> pointer to something entered by a user. That's when things become 
> interesting, since in architectures like x86 that can overwrite the 
> stack frame, and with a well crafted overwrite you can make someFunction 
> to return to your own bad code.

That would be an architecture issue, not a language issue.