From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 40EB31F5AE for ; Sat, 15 May 2021 14:04:34 +0000 (UTC) Received: from localhost ([::1]:37768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhuu9-0005qu-69 for normalperson@yhbt.net; Sat, 15 May 2021 10:04:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44180) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhuu5-0005ql-Nh for bug-gnulib@gnu.org; Sat, 15 May 2021 10:04:29 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:44027) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lhuu1-0005UM-3v for bug-gnulib@gnu.org; Sat, 15 May 2021 10:04:29 -0400 Received: by mail-wr1-x431.google.com with SMTP id s8so1869908wrw.10 for ; Sat, 15 May 2021 07:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lMqmYm1onvZRvf7arNVEQXMyDVXTvls7N9R4Zfr4Qt4=; b=UAV0JoEhRfKMJ4IY6A7fEUyiyxCLKRf1yfoZsqevkLZbLLrVOiZTiU7O5lhV+wFInD xcGMR2ZjLzms/lqQg/7rXMa22wspS4W89n5MANqE+IeX/jCzi5KIAabpNIcBLz9oNL8J +E/PVY8M+gffiXbO31pVFGJDp9yYZtSIgNeGy9IhGIKjRqltz7+2Xvm38hYpguIQQxt3 0PgMGc1IxiayUyXzv1+k7ekBcJLjPEqo2RWp2CwV5nQrH9zsPSBYJzvtOzB3Xtm4tdBV LsndQ20NUMVPDb8rlupVOSfiPSjPYa00YFeeoR0p52k+T2/La/BmVyBU79ti84bkNLHz dQbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lMqmYm1onvZRvf7arNVEQXMyDVXTvls7N9R4Zfr4Qt4=; b=W8QAp4dNCDOhv+aS1irM7Bn1tTzYEabIK2OfKk7XgaE/hnXqOXwe55UDVVwGSUxkJN LDbheUMHJkFTjGIws83gxIIx5L8x61+qY2HXivZuzMXuxmld/bwD/4a1gxLEQumTOcpl RLoBhABW5b+sLLtuESTS6bWqmD/WJD41soK1lt2K6xZocymNXBWKVynWE8xMcloftP0t reZGKVZuGpUVI6wr7fXagcgWVH2vgado3zvh0WRNbFM8VAFKuJjFlvE5grbb0ERjeI5N anHWmU3sj8tXHGVqnNCqbvr+6FbAVdKg/RHGbws6aUoX+v7Y9nvNw1K6sgQ1dYq9ANyt zeqg== X-Gm-Message-State: AOAM531ZDpA9zmsGe9BsBht9sq6cLy0xfblp0tjRQjtkn99+7gYSvnMO HemF4NviW0JpZu7ceWlJdxiFQpUV1QZ+hA== X-Google-Smtp-Source: ABdhPJz8mo7IABeLjkynkYifAADKyytlxCUorpK8vQN6QwQ+JX3TDq2511eSPJGNJq2tepsmdF7wPw== X-Received: by 2002:a5d:64e6:: with SMTP id g6mr63466112wri.216.1621087462389; Sat, 15 May 2021 07:04:22 -0700 (PDT) Received: from localhost.localdomain (86-42-14-227-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.42.14.227]) by smtp.googlemail.com with UTF8SMTPSA id p10sm8872007wmq.14.2021.05.15.07.04.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 May 2021 07:04:21 -0700 (PDT) Subject: Re: *alloc-gnu on glibc To: Bruno Haible , bug-gnulib@gnu.org References: <2032454.zAlmhYMddX@omega> From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: Date: Sat, 15 May 2021 15:04:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Thunderbird/84.0 MIME-Version: 1.0 In-Reply-To: <2032454.zAlmhYMddX@omega> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=pixelbeat@gmail.com; helo=mail-wr1-x431.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On glibc-2.31-5.fc32.x86_64 I'm seeing this test failure with coreutils, since the tests are now checking for a specific errno. I just checked a later Fedora 34 system which has the same issue. Specifically test-realloc-gnu is enabled in coreutils and it's failing as realloc is returning NULL as expected, but errno is 0. Specifically on glibc realloc(NULL, PTRDIFF_MAX+1) does return 0,errno=ENOMEM, but realloc(non_null, PTRDIFF_MAX+1) returns 0,errno=0. I'm wondering should we be more relaxed here as, there is only one standardised ENOMEM error from realloc, so code doesn't have to behave differently based on what the errno is. Especially if it's using xrealloc etc. Now I accept that error messages may be more accurate, but one should opt into that I think. Should we adjust things so depending on realloc-gnu would not have the more stringent requirement of ENOMEM being returned from realloc(), and for projects that wanted that, they could depend on the realloc-posix module instead? In any case I'd be in favor of relaxing the test, rather than replacing realloc everywhere. some notes on solaris below... On 14/05/2021 18:04, Bruno Haible wrote: > On Solaris 11.3 (the machine gcc211.fsffrance.org, in 64-bit mode), there > are test failures: > FAIL: test-calloc-gnu > FAIL: test-malloc-gnu > FAIL: test-realloc-gnu > FAIL: test-reallocarray > Each of these tests takes about 30 seconds before failing, and is not > immediately reactive to Ctrl-C. These EAGAIN failure modes sound like the value passed to realloc() etc. is too small to ensure ENOMEM was return immediately. I've not looked into how the compiler for the m4 test is invoked, but I did check the code in isolation on a 64 bit solaris 10 system. The following shows that it's important to ensure the compiler is explicitly running in 64 bit mode, as the default is 32 bit, resulting in 32 bit longs and hence too small of values passed in: > gcc malloc-m4.c > ./a.out PTRDIFF_MAX = 2147483647 p=20f90 errno=0 p=0 errno=12 p=0 errno=12 > gcc -m64 malloc-m4.c > ./a.out PTRDIFF_MAX = 9223372036854775807 p=0 errno=12 p=0 errno=12 p=0 errno=12 Both the above returned immediately for me. Though I also notice the existing note in malloc.m4 on this check being too dangerous to run in general due to this issue. cheers, Pádraig