From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-79086-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 90684 invoked by alias); 5 May 2017 22:31:46 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 90658 invoked by uid 89); 5 May 2017 22:31:45 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=realistic, interest, serious
X-HELO: zimbra.cs.ucla.edu
Subject: Re: [PATCH] Dynamic growable arrays for internal use
To: Florian Weimer <fweimer@redhat.com>,
 Joseph Myers <joseph@codesourcery.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
References: <edae68d6-998b-58a6-a8df-82703341da23@redhat.com>
 <alpine.DEB.2.20.1704241401140.28943@digraph.polyomino.org.uk>
 <373c24b0-4d73-cf0a-b264-8a958aff6f2b@redhat.com>
 <75225ee3-2ae6-7a19-07be-e33818a43ac5@cs.ucla.edu>
 <2c8be504-90ad-6178-6698-fe61308af98c@redhat.com>
From: Paul Eggert <eggert@cs.ucla.edu>
Message-ID: <19e17934-972c-56b6-bb38-2ed5e9dfa4af@cs.ucla.edu>
Date: Fri, 05 May 2017 22:31:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <2c8be504-90ad-6178-6698-fe61308af98c@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2017-05/txt/msg00114.txt.bz2

On 05/05/2017 08:23 AM, Florian Weimer wrote:
> You just have to be careful with pointer differences.

Not just with pointer differences, but also in index and size calculations.

Although the problem is in the calling code not in the module itself, it 
is a common problem, and unfortunately it can lead to serious issues 
that are not easily detected because unsigned arithmetic is well-defined 
to wrap around. In practice, just saying "callers must be careful" is 
not good enough.

As no realistic user of this module should need to allocate objects 
containing more than PTRDIFF_MAX bytes, it is a reasonable engineering 
decision for it to reject such objects in the interest of overall glibc 
reliability.