220 3820 <51753F5E.9060108@redhat.com> article Path: news.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: N3639 and exceeding implementation limits at run time Date: Mon, 22 Apr 2013 15:47:10 +0200 Lines: 31 Approved: news@gmane.org Message-ID: <51753F5E.9060108@redhat.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Trace: ger.gmane.org 1366638437 17662 80.91.229.3 (22 Apr 2013 13:47:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2013 13:47:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRZV4PDR4PBBZH62SFQKGQE5GJ5LBQ@isocpp.org Mon Apr 22 15:47:19 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f200.google.com ([209.85.160.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UUH5S-0008Ar-Hc for gclcip-std-proposals@m.gmane.org; Mon, 22 Apr 2013 15:47:18 +0200 Original-Received: by mail-gh0-f200.google.com with SMTP id 10sf2795470ghy.11 for ; Mon, 22 Apr 2013 06:47:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-beenthere:x-received:received-spf:message-id:date:from :user-agent:mime-version:to:subject:x-scanned-by:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=bEXm/N+wakcsnqU7vG7W2SGVZygNUPDadUkrxbgpFwk=; b=PJ59GUMhYLB7tw3r5ZHjG9DbRDXshDJIPQ1vxZAOqrcrJRrasm9OQi7CI0fTwYl92u oELv5w7UqjHPiR62gEsPXpVCgcGje+ZodWkhObkradgDJDNXAA7cEKYuAOhMLPL0MzYO iEPmKPVLrL+YgxPiOGilH2OJsOLz83pagfWdwk8TtxibcLOZht+hYCS8SRhCzVWO+Vrk LQu2ByeGXUfxhBMq1saWQc7HbeQ6P0xJhR37IfmAe0ZpUGHVVUQaF2kZeqiPNN8COMJr jxxfB/AFc+1UE2V+BBkBSlGEYCWP0QvAZJF2sMUC4q7i7N6IdBhuJj9axnhp9n32cuyu X-Received: by 10.236.161.234 with SMTP id w70mr13402163yhk.22.1366638437513; Mon, 22 Apr 2013 06:47:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.105.161 with SMTP id gn1ls3046685qeb.64.gmail; Mon, 22 Apr 2013 06:47:14 -0700 (PDT) X-Received: by 10.224.79.194 with SMTP id q2mr21798765qak.61.1366638434236; Mon, 22 Apr 2013 06:47:14 -0700 (PDT) Original-Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTP id d5si7808310qao.0.2013.04.22.06.47.13; Mon, 22 Apr 2013 06:47:14 -0700 (PDT) Received-SPF: pass (google.com: domain of fweimer@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Original-Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3MDlDr8032642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 22 Apr 2013 09:47:13 -0400 Original-Received: from oldenburg.str.redhat.com (ovpn-116-42.ams2.redhat.com [10.36.116.42]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r3MDlBZR006500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Apr 2013 09:47:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Original-Sender: fweimer@redhat.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of fweimer@redhat.com designates 209.132.183.28 as permitted sender) smtp.mail=fweimer@redhat.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:3820 Archived-At: It seems that in C++11 and earlier, exceeding certain implementation limits at run time leads to undefined behavior (in the sense that the standard does not define what happens). This applies to the various forms of stack overflow (although C++ does not have the concept of a stack of function activation frames as such). I wonder if N3639 intends to change this and if implementations are expected to check that the current activation plus the requested VLA does not exceed any run-time implementation limit. The presence of the bullet item "its value is such that the size of the allocated object would exceed the implementation-defined limit (annex B implimits)" suggest to me that such a check is required, but it's not entirely to which limit the item refers. At least on some systems, this check is somewhat difficult to implement in an efficient manner if it is indeed intended to guarantee that no undefined behavior occurs independently of the size of the VLA. -- Florian Weimer / Red Hat Product Security Team -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en. .