Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1655

Re: Second draft, "Safe arrays and pointers for C"

Show all headers | View raw

On 9/2/2012 3:20 PM, Hans-Bernhard Bröker wrote:
> On 01.09.2012 02:26, John Nagle wrote:
>
>>     Not really.  The main use case for unions is for data read
>> in from an external source, often a network.
>
> No, it's not, because the vast majority of usages of unions for that
> purpose would automatically cause undefined behaviour.
>

yeah, and also most cases I have seen unions used for have little to do 
with network data.


>>     Tightening down the screws further on that would alienate too many C
>> programmers.  Consider the common idiom
>>
>>     const char* msg[] =
>>     {"First message", "second message", "third message", 0 }
>

(ironically, the above will probably only work without issue in C++, and 
in C will usually generate a message something like "warning: int to 
pointer conversion without a cast" or similar... this means the array 
needs to be terminated with either NULL or "((void *)0)" or "((char 
*)0)" or similar to avoid the compiler complaining about it).


> And that would run afoul of reading beyond the end of the array ... how?
>

dunno what he was thinking here...

my guess is maybe that unless whatever is used as an index is clamped, 
it may go beyond the end of the array.

but, then, usually in cases like these, a person is using a number that 
they know is an index into the array, so it isn't much of an issue.


>> Or even
>>     int main(int argc, const char* argv[]);
>>
>> Most security attacks require write access.
>
> Let's hold it right here for a moment.  So what is it you're trying to
> avoid: attacks or program crashes?  The distinction is quite important,
> because actual security attacks need write access a whole lot less than
> crashing programs would.  You can expose secret data by random reading,
> but it's a whole lot harder to crash a program that way.
>

yep.


>>      C99 VLA parameters seem to be on the way out, anyway.
>
> That hasn't become any less incorrect since the last time round.

yep.


in my own ideas, usually, a bounds-checked array index or similar would 
be redirected to the runtime, which would attempt to look up the object, 
and then check the types and index (operations such as 
pointer-arithmetic would be bounds-checked as well).

in this case, the compiler+runtime would make provisions for keeping 
track of types and performing bounds-checks and type-checks, and so this 
would usually come at a performance cost (need not be prohibitive, if 
designed well).

in this case, both language and ABI compatibility could be maintained 
(if the physical representation of the data is maintained, generally 
because out-of-band metadata would be used to keep track of things).

note: a design goal is to keep the pointer-lookups reasonably fast. 
usually, this involves a little care in the design of a memory manager, 
but the lookups can often be reduced to an O(1) average case (and an 
O(log n) worst case).

note: by metadata, I am imagining more specialized type information, not 
the use of generic debug information.


the open question would be how to best handle the case of interaction 
with outside code or data, which may provide pointers which lack visible 
type information, requiring either being "lax" (allowing unchecked 
operations in these cases), or "strict" (say, raising a signal or OS 
exception).


not that I expect such an idea would be universally applicable, but 
could be useful for "untrusted" code, for debugging purposes, and code 
which is "generally not CPU bound" (less need to care about performance 
of code when the CPU is mostly sitting around idle).

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-30 12:48 -0700
  Re: Second draft, "Safe arrays and pointers for C" pacman@kosh.dhis.org (Alan Curry) - 2012-08-31 22:17 +0000
    Re: Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-31 17:26 -0700
      Re: Second draft, "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-09-02 22:20 +0200
        Re: Second draft, "Safe arrays and pointers for C" BGB <cr88192@hotmail.com> - 2012-09-03 10:55 -0500
          Re: Second draft, "Safe arrays and pointers for C" Ike Naar <ike@iceland.freeshell.org> - 2012-09-03 16:39 +0000
            Re: Second draft, "Safe arrays and pointers for C" BGB <cr88192@hotmail.com> - 2012-09-03 13:18 -0500
  Re: Second draft, "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-02 10:52 +0200
  Re: Second draft, "Safe arrays and pointers for C" Per <per.mathisen@gmail.com> - 2012-09-28 06:49 -0700
    Re: Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-09-28 11:36 -0700
      Re: Second draft, "Safe arrays and pointers for C" Per <per.mathisen@gmail.com> - 2012-10-01 09:38 -0700
        Re: Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-10-01 11:38 -0700
      Re: Second draft, "Safe arrays and pointers for C" Shao Miller <sha0.miller@gmail.com> - 2012-12-17 09:11 -0500
        Re: Second draft, "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-12-17 10:18 -0800
          Re: Second draft, "Safe arrays and pointers for C" Shao Miller <sha0.miller@gmail.com> - 2012-12-17 18:24 -0500
            Re: Second draft, "Safe arrays and pointers for C" Shao Miller <sha0.miller@gmail.com> - 2012-12-17 18:32 -0500
            Re: Second draft, "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-12-17 15:44 -0800

csiph-web