From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82742 invoked by alias); 5 May 2017 15:13:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 80278 invoked by uid 89); 5 May 2017 15:13:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:D*ucla.edu, H*r:sk:zimbra., H*RU:sk:zimbra., HX-HELO:sk:zimbra. X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH] Dynamic growable arrays for internal use To: Florian Weimer , Joseph Myers References: <373c24b0-4d73-cf0a-b264-8a958aff6f2b@redhat.com> Cc: GNU C Library From: Paul Eggert Message-ID: <75225ee3-2ae6-7a19-07be-e33818a43ac5@cs.ucla.edu> Date: Fri, 05 May 2017 15:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <373c24b0-4d73-cf0a-b264-8a958aff6f2b@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00108.txt.bz2 Florian Weimer wrote: > Does anyone have comments about the interface and implementation? It suffers from a common problem: it can allocate objects containing more than PTRDIFF_MAX bytes. Such objects do not work in C, because pointer subtraction has undefined behavior (and in practice does not work even if the correct result would be representable as ptrdiff_t). At a minimum I suggest adding a ptrdiff_t overflow check to __check_mul_overflow_size_t so that it reports overflow if the result exceeds PTRDIFF_MAX. In applications I am starting to take the lead of the GNU Emacs internals, and to prefer ptrdiff_t to size_t when calculating sizes. This allows for better automated checking of integer overflow in size calculations, since ptrdiff_t overflow has undefined behavior and can be caught by -fsanitize=undefined. I suggest doing this in this new module, and if it works well we should consider doing it elsewhere in glibc. Of course this problem affects other code in glibc, but one thing at a time.