Changing the meaning of the array indexing brackets "[ ]" to do bounds checking and then ...

On 3 Nov, 00:52, Casey Hawthorne <caseyhHAMMER_T...@istar.ca> wrote:
> On Mon, 02 Nov 2009 15:18:21 -0800, Keith Thompson <ks...@mib.org>
> wrote:
>
>
>
>
>
> >jacob navia <ja...@nospam.org> writes:
> >> Casey Hawthorne a ?crit :
> >>> Changing the meaning of the array indexing brackets "[ ]" to do bounds
> >>> checking and then using another notation for array indexing without
> >>> bounds checking, say "[| |]", might help minimize buffer overruns.
>
> >>> By default, previous programs would have bounds checking turned on,
> >>> unsless explicilty turned off.
>
> >> The lcc-win C compiler implements this. It is called "operator
> >> overloading".
>
> >> You can define your own [ ] operators, and the compiler will call
> >> your function that can do bounds checking in the array.
> >[...]
>
> >Does lcc-win allow a [] operator to be defined for existing types that
> >already have a built-in [] operator? *For example, can I do something
> >like this (I'm not sure of the syntax)?
>
> > * *int operator[](int *arr, size_t index)
> > * *{
> > * * * *return /* something */;
> > * *}
>
> >I suspect the answer is no.
>
> >I think the OP is suggesting changing the semantics of the existing
> >built-in [] operator, so that existing code gains bounds checking
> >with no modifications to the source.
>
> >Of course implementations are already allowed to do this, even
> >without operator overloading. *All cases in which a bounds check
> >would fail invoke undefined behavior anyway, so the implementation
> >is free to generate code that detects the error.
>
> >The overhead would be substantial, since you'd need fat pointers to
> >retain bounds information for function parameters. *And it would
> >break some existing code whose behavior is, strictly speaking,
> >undefined, but that works in practice. *The most obvious examples
> >are the "struct hack" (which could be modified to use the C99 feature
> >that replaces it, but the point is to avoid changing the source), and
> >code that treats a multidimensional array as a one-dimensional array.
>
> >Code that avoids these odd corners of the language could certainly
> >benefit from a bounds checking implementation. *And in fact I believe
> >such implementations exist, though I don't know if they go so far as
> >to implement fat pointers to enable checking on pointer parameters.
> >(At the very least, *testing* code under such an implementation could
> >be instructive.)
>
> I thought of this question, of buffer overruns, after one of the
> people interviewed for the book "Coders at Work" said that C was great
> for systems programming by well trained programmers, but that C had
> leaked out into the applications area.
> For systems programming you do need the access to the machine that C
> provides, but for applications programming, you don't need/shouldn't
> have such access.

I'm nor sure the distinction is as clean as you'd like. Are
communication protocols system or application? What about embedded
programming? I suppose C-Hash's Safe and Unsafe modes (or whatever
they're called) might be a way to go.

Nick Keighley

Nick Keighley wrote:
> On 3 Nov, 00:22, "bartc" <ba...@freeuk.com> wrote:

>> The OP is only talking about arrays, and not pointers.
>
> can you really do that?
>
> void process_ptr (char*);
> void process_arr (char[]);
>
> Do they take the same type? They do in C but do they in Hawthorne-C?

>
>> But these are
>> inextricably linked so I guess we need 'proper' arrays, ie. distinct
>> from the sort of arrays/pointers currently in C.
>
> I don't think you have C anymore...

I think it can be done by adding a type, 'checked array' or some such name.
But you can't mess around with these as freely as you can with regular
arrays.

A pointer to an element is possible, but then you aren't protected if you
decide to derefence that pointer with a too-large offset. But you can
probably create a slice instead, which is another checked array.

The implementation? Probably just another fat pointer (pointer+length), but
ring-fenced for extra protection.

>> Then there wouldn't be all this
>> baggage to make the implementation of array bounds 'impossible'.
>> That's still a major language extension though.
>
> looks a language redesign to me. Why not just abolish pointers and
> call it Java?

Switching language is one solution.

--
Bartc

bartc

Casey Hawthorne wrote:

> Changing the meaning of the array indexing brackets "[ ]" to do bounds
> checking and then using another notation for array indexing without
> bounds checking, say "[| |]", might help minimize buffer overruns.
>
> By default, previous programs would have bounds checking turned on,
> unless explicitly turned off.

You might find the following articles interesting.

http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging
http://gcc.fyxm.net/summit/2003/mudflap.pdf

On an unrelated note, it seems like the mudflap library itself recently
introduced a vulnerability.

http://xorl.wordpress.com/2009/11/01...ode-execution/

Noob

bartc wrote:
> [... array bounds checking ...]
>
> I think it can be done by adding a type, 'checked array' or some such
> name. But you can't mess around with these as freely as you can with
> regular arrays.
>
> A pointer to an element is possible, but then you aren't protected if
> you decide to derefence that pointer with a too-large offset. [...]

So, no protection for

checked_array char hello[5];
strcpy (hello, "Hello there, world, old buddy, old pal!");

? Seems to me this is exactly the use case the O.P. tries to
address! You might want to re-count the babies after throwing
out the bathwater ...

Or you could forbid using a checked_array with library
functions that take pointers, which would make checked_array
pretty useless. Or you could implement an entire parallel
suite of library functions to handle checked_arrays instead
of pointers. There'd be a certain amount of bloat: strcpy()
alone would need four versions, and I don't want to *think*
about scanf() ...

--
Eric Sosman
lid

Eric Sosman

"Eric Sosman" <> wrote in message
news:hcpddc$qra$...
> bartc wrote:
>> [... array bounds checking ...]
>>
>> I think it can be done by adding a type, 'checked array' or some such
>> name. But you can't mess around with these as freely as you can with
>> regular arrays.
>>
>> A pointer to an element is possible, but then you aren't protected if you
>> decide to derefence that pointer with a too-large offset. [...]
>
> So, no protection for
>
> checked_array char hello[5];
> strcpy (hello, "Hello there, world, old buddy, old pal!");

The checked_array is just converted to a normal pointer in this case.

>
> ? Seems to me this is exactly the use case the O.P. tries to
> address! You might want to re-count the babies after throwing
> out the bathwater ...

The OP was talking about indexing arrays. strcpy() and friends are mainly
about pointers.

> Or you could forbid using a checked_array with library
> functions that take pointers, which would make checked_array
> pretty useless.

A warning would suffice.

Or you could implement an entire parallel
> suite of library functions to handle checked_arrays instead
> of pointers. There'd be a certain amount of bloat: strcpy()
> alone would need four versions, and I don't want to *think*
> about scanf() ...

It's possible an implementation might have parallel versions of some
functions (ones that write to an array), and make it so that their use is
transparent.

Strcpy wouldn't need 4 versions, just two. And the one taking the
checked_array param can just be implemented in terms of a regular function.
Or maybe there can just be one version, the one with checked_array
(requiring widening of an ordinary pointer to a fat pointer with no upper
limit).

--
bartc

bartc

Casey Hawthorne wrote:

> Changing the meaning of the array indexing brackets "[ ]" to do bounds
> checking and then using another notation for array indexing without
> bounds checking, say "[| |]", might help minimize buffer overruns.
>
> By default, previous programs would have bounds checking turned on,
> unsless explicilty turned off.

What is your opinion of Cyclone?

http://cyclone.thelanguage.org/wiki/...%20Programmers
http://en.wikipedia.org/wiki/Cyclone...mming_language)

"""
Cyclone attempts to avoid some of the common pitfalls of the C
programming language, while still maintaining the look and performance
of C. To this end, Cyclone places the following restrictions upon programs:

* NULL checks are inserted to prevent segmentation faults
* Pointer arithmetic is restricted
* Pointers must be initialized before use (this is enforced by
definite assignment analysis)
* Dangling pointers are prevented through region analysis and
limitations on free()
* Only "safe" casts and unions are allowed
* goto into scopes is disallowed
* switch labels in different scopes are disallowed
* Pointer-returning functions must execute return
* setjmp and longjmp are not supported
"""

Regards.

Noob