This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Improve check against integer wraparound in hcreate_r [BZ #18240]
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Florian Weimer <fweimer at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, <nd at arm dot com>
- Date: Mon, 1 Feb 2016 17:12:43 +0000
- Subject: Re: [PATCH] Improve check against integer wraparound in hcreate_r [BZ #18240]
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <56A210C4 dot 80609 at redhat dot com> <56A42D78 dot 1030506 at cs dot ucla dot edu> <877fixs9or dot fsf at mid dot deneb dot enyo dot de> <56A6B883 dot 2070801 at cs dot ucla dot edu> <56A8F5C0 dot 2070307 at redhat dot com> <56AF8B5A dot 3050304 at arm dot com> <mvm37tc9xa8 dot fsf at hawking dot suse dot de>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 01/02/16 17:05, Andreas Schwab wrote:
> Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
>
>> i think the test-skeleton changes malloc behaviour
>> in weird ways, but i'm not yet sure what's going on.
>
> mallopt (M_PERTURB, 42);
>
ok, so if the only line in main() is
calloc(INT_MAX-2, 24);
then it does the memset, but if i do
calloc (500, 24);
calloc (INT_MAX-2, 24);
then it does not, however
mallopt (M_PERTURB, 42);
calloc (500, 24);
calloc (INT_MAX-2, 24);
again does the memset (and this is what happens
in the actual test).
given the unreliable calloc behaviour i think
glibc should avoid such tests.
does it affect other 64bit targets?