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 would very likely be "build one to throw away" - features built
>> without a clear definition of how they interact with other language
>> features have been particularly problematic in the past. So have
>> extensions built based on "take this feature from another language, and
>> put it in GNU C".
>
> The alternative is worse: to design and fully specify a language
> feature and suggest that people adopt it without at any point trying
> that feature in real applications.
>
>>> will provide useful information about the amount of work likely to be
>>> needed to complete the task. Also, it will provide the opportunity to
>>> try out the language feature to see how well it works in practice.
>>
>> Whether people *will* use it is probably the more significant question
>> than whether it *can* be used to address particular issues.
>
> Well, of course. But the only way to find out is by an iterative
> process: design something, try it, and refine. Supporting that is one
> of GCC's primary goals, and has been since the beginning of the
> project.
>
> Andrew.
>
Exactly. That's why I'm raising this issue on the GCC list.
GCC already has many of the necessary extensions, such as
forward parameter declarations. It has VLAs on the C side,
and references on the C++ side. So most of the necessary
machinery is already implemented within GCC.
A first step would be a GCC version which allowed variable
length arrays in references and structures, but only made
the array parameter size checks, not full subscript checks.
That would allow trying to port some code over to strict mode,
and would wring out the concept.
Think of it as FORTIFY on steroids. It can do the parameter
checks FORTIFY does, but for any function with an array parameter
and a size. It's not limited to a built-in list of the usual
suspect functions.
John Nagle
