From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52138 invoked by alias); 12 Apr 2017 16:35:17 -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 51635 invoked by uid 89); 12 Apr 2017 16:35:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4BFCF7FD42 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4BFCF7FD42 Subject: Re: [PATCH] Add reallocarray function. To: =?UTF-8?Q?Dennis_W=c3=b6lfing?= , libc-alpha@sourceware.org References: <20170410150053.10208-1-denniswoelfing@gmx.de> <7bccc976-7a3e-4ffa-5e2c-767f3e3c9658@gmx.de> From: Florian Weimer Message-ID: Date: Wed, 12 Apr 2017 16:35: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: <7bccc976-7a3e-4ffa-5e2c-767f3e3c9658@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-04/txt/msg00218.txt.bz2 On 04/12/2017 05:24 PM, Dennis Wölfing wrote: > The static inline function check_mul_overflow is used in both > reallocarray and calloc. So that function would need to be in a file > that can be included by both malloc.c and a new reallocarray.c file. > > Would malloc-internal.h be a good location to put that inline function > or should I place it into its own separate file? Use malloc-internal.h or create a new malloc-private.h header. malloc-internal.h is used for things which are used in other glibc modules (fork handler and ld.so), but we aren't fully consistent yet about the distinction in other areas of the library. Thanks, Florian