Here's the September 2012 draft of my "Safe arrays and pointers for C"
proposal:
http://www.animats.com/papers/languages/safearraysforc43.pdf
This incorporates most of the substantive issues raised in
previous discussions.
Brief summary:
- Optional "strict mode" via pragma which prohibits some
On 9/3/2012 8:29 AM, Andrew Haley wrote:
> On 09/03/2012 04:20 PM, Joseph S. Myers wrote:
>> On Mon, 3 Sep 2012, Andrew Haley wrote:
>>
>>> This isn't the only way to proceed. I'd encourage someone wanting to
>>> do this to branch GCC and implement a rough cut of the feature. That
>>
>> That woul
On Mon, 3 Sep 2012, Florian Weimer wrote:
> its implementation costs. Part of that is related to the reluctance to use
> fat pointers (although they are implicit in some places, such as the return
> value of array_slice). Code can write to length parameters and struct fields
While I like fat po
On 09/03/2012 04:20 PM, Joseph S. Myers wrote:
> On Mon, 3 Sep 2012, Andrew Haley wrote:
>
>> This isn't the only way to proceed. I'd encourage someone wanting to
>> do this to branch GCC and implement a rough cut of the feature. That
>
> That would very likely be "build one to throw away" - fe
On Mon, 3 Sep 2012, Andrew Haley wrote:
> This isn't the only way to proceed. I'd encourage someone wanting to
> do this to branch GCC and implement a rough cut of the feature. That
That would very likely be "build one to throw away" - features built
without a clear definition of how they inte
On 08/31/2012 11:55 PM, John Nagle wrote:
The proposal,
"Safe arrays amd pointers for C, round 2", is here:
http://www.animats.com/papers/languages/safearraysforc41.pdf
The typedef at the top of page 9 is incorrect or needs an explanation.
At the top of page 13, the example references an "it
On 09/01/2012 05:09 PM, Joseph S. Myers wrote:
> Adding references to C would likely have consequences throughout the
> entire language standard. Producing the proper specification for this
> would be a large amount of work for someone with extensive expertise in
> the standard (and in the C++
On 9/2/2012 1:12 AM, Florian Weimer wrote:
> * John Nagle:
>
>>We have proposed an extension to C (primarily) and C++ (possibly)
>> to address buffer overflow prevention. Buffer overflows are still
>> a huge practical problem in C, and much important code is still
>> written in C. This is a
On Sat, Sep 1, 2012 at 8:35 PM, John Nagle wrote:
> On 9/1/2012 9:59 AM, James Dennett wrote:
>> On Fri, Aug 31, 2012 at 2:55 PM, John Nagle
>> wrote:
>>> We have proposed an extension to C (primarily) and C++ (possibly)
>>> to address buffer overflow prevention. Buffer overflows are still
>>> a
On 9/1/2012 9:59 AM, James Dennett wrote:
> On Fri, Aug 31, 2012 at 2:55 PM, John Nagle
> wrote:
>> We have proposed an extension to C (primarily) and C++ (possibly)
>> to address buffer overflow prevention. Buffer overflows are still
>> a huge practical problem in C, and much important code i
On Fri, Aug 31, 2012 at 2:55 PM, John Nagle wrote:
>We have proposed an extension to C (primarily) and C++ (possibly)
> to address buffer overflow prevention. Buffer overflows are still
> a huge practical problem in C, and much important code is still
> written in C. This is a new approach t
On Fri, 31 Aug 2012, John Nagle wrote:
> On 8/31/2012 3:32 PM, Joseph S. Myers wrote:
> > My comments are:
> >
> > * TL;DR.
>
>Then, perhaps, commenting is premature.
The alternative would have been to ignore your message completely (having
already concluded based on the initial comp.std.c
On 8/31/2012 3:32 PM, Joseph S. Myers wrote:
> My comments are:
>
> * TL;DR.
Then, perhaps, commenting is premature.
> * No specification given at the level of edits to C11.
That's correct. This is still an informal proposal.
> * At a glance, no or inadequate explanation of why library s
My comments are:
* TL;DR.
* No specification given at the level of edits to C11.
* At a glance, no or inadequate explanation of why library solutions and
appropriate coding practices (such as the use of managed string libraries)
are inadequate.
* How does this compare to the array size checki
14 matches
Mail list logo