[LLVMdev] C as used/implemented in practice: analysis of responses

Sean Silva chisophugis at gmail.com
Thu Jul 2 18:22:22 PDT 2015


On Thu, Jul 2, 2015 at 5:43 PM, David Keaton <dmk at dmk.com> wrote:

> On 07/02/2015 05:30 PM, Philip Reames wrote:
>
>>
>>
>> On 07/02/2015 04:44 PM, David Keaton wrote:
>>
>>> On 07/02/2015 03:17 AM, Kuperstein, Michael M wrote:
>>>
>>>> You want to redefine ["won't break the program"], by specifying a new
>>>> abstract machine, which is
>>>> more conservative than standard C/C++. The proper way to do that would,
>>>> I believe, be to work towards setting up a working group within the
>>>> relevant committees, and come up with a uniformly accepted definition
>>>> for this abstract machine, which could then be implemented (assuming
>>>> there is, indeed, wide enough agreement in the implementer community –
>>>> something that does not look at all likely) by next-generation
>>>> compilers.
>>>>
>>>
>>>      This work has already been done in Annex L of the C standard,
>>> which provides an optional stricter abstract machine.  As far as I
>>> know, no implementations have attempted to support Annex L yet.
>>>
>> Do you have a link to the relevant text?  I've never heard of this, and
>> a quick google search doesn't turn up anything relevant. Wikipedia knows
>> about a set of "analyzability features", but that doesn't sounds like
>> what you're talking about?
>>
>
>      The relevant text is inside the standard, which is for sale.  The
> cheapest source I know about is this.
>
>
> http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2fISO%2fIEC+9899%3a2011%5b2012%5d


"Final draft" is available at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

-- Sean Silva


>
>
>      The title of Annex L is Analyzability, because that was the purpose,
> but the effect was to define a stricter abstract machine in which there
> were no unbounded undefined behaviors except what was absolutely
> necessary.  That does not address every question in the questionnaire, but
> it is a good start, and it has already been standardized so there is
> something concrete to implement.
>
>
>                                         David
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/90235520/attachment.html>


More information about the llvm-dev mailing list