From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22588 invoked by alias); 14 Mar 2015 13:58:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22578 invoked by uid 89); 14 Mar 2015 13:58:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-we0-f177.google.com Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com) (74.125.82.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 14 Mar 2015 13:58:35 +0000 Received: by wegp1 with SMTP id p1so9651215weg.1 for ; Sat, 14 Mar 2015 06:58:33 -0700 (PDT) X-Received: by 10.194.223.103 with SMTP id qt7mr101564914wjc.35.1426341512917; Sat, 14 Mar 2015 06:58:32 -0700 (PDT) Received: from [10.36.249.228] (089144192228.atnat0001.highway.a1.net. [89.144.192.228]) by mx.google.com with ESMTPSA id lu13sm7106065wic.10.2015.03.14.06.58.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 06:58:32 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <20150314130238.GD16488@bubble.grove.modra.org> References: <20150314130238.GD16488@bubble.grove.modra.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: Fix for PRs 36043, 58744 and 65408 From: Bernhard Reutner-Fischer Date: Sat, 14 Mar 2015 13:58:00 -0000 To: Alan Modra ,gcc-patches@gcc.gnu.org Message-ID: <6E83247A-F634-43AA-A3F1-249F99AE7719@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00777.txt.bz2 On March 14, 2015 2:02:38 PM GMT+01:00, Alan Modra wrote: >I'll also throw together a testcase or three. For execute tests I'm >thinking of using sbrk to locate an odd sized struct such that access >past the end segfaults, rather than mmap/munmap as was done in the >pr36043 testcase. Does that sound reasonable? Well since sbrk was marked LEGACY in SUSv2 and was removed in SUSv3 (and still is in 1003.1-2008) I'm not sure it is wise to use it in new code.. Using it will bite testing on legacy-free setups, fwiw. Cheers,