From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by sourceware.org (Postfix) with ESMTPS id C15693858D1E for ; Wed, 1 Nov 2023 19:30:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C15693858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C15693858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=131.179.128.66 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698867056; cv=none; b=PBgPhT2xujQfI+r4/pDV7JMCdFO3IkuFQIk3JONhkgsoYDIiOJDdMi+DCP3fVoZF7jlwNm3t7t8kohLTvyhMjQTGlhUM8qMC/1VhuWwnNtiwc04fWSoccAVhMZUEwwG72E75Z7nZvuBQa3bc0nVYXvTCSNxVDpZ2QVGDE/qQkVI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698867056; c=relaxed/simple; bh=DW1RlOcBGDzSMWiOfwAOP6IskdSgm8eujUGFhcdWFkY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=jD+lbBgyTFePglQbmYhx+CXv6DBr9ZwtWbkFLX6/RxO8yGFAPqc1qaQzDaMs9ddGd5nhkI5cpxXlmzXu16hCigmEQVqIaiUZBgfskeah5liqk6PkKD3/NJfgNtHQu0pjXf8GxEqttZ8jT9k0qVWPfAw/oeB6if/iE/LagBhHXwc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id CEB0A3C00D235; Wed, 1 Nov 2023 12:30:44 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7KxykQixuC67; Wed, 1 Nov 2023 12:30:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 7037F3C00D236; Wed, 1 Nov 2023 12:30:40 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 7037F3C00D236 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1698867040; bh=WbLpipdJdV1vP8Ye95XP9DRtVutpsrz/epm7xO7c6XU=; h=Message-ID:Date:MIME-Version:To:From; b=RF9XNAW61NkG1h5gDPwMIj2qEKsZJLlGvcUkqxWVDeTQ26UynFzLcagby1KN+3gk3 dTlWK/+GheEC+7rp+DrXJZW6CuiYnbx9vySEDJc5MxpHNlaigLiRz3eiP3O3hc2BI1 tZO0yzXQRlPgyUtF6cS4v/wUSdQBPnK9t2lJmcujUaoLlxrgjSiYUAKAOqqn4zcED1 AoMeLLxR/9RB+c5VLt6WJlSJOmhCRbdqh86hG6ToooMgTtYB52ReLAFXtU4wEU/WPc s8yW270S0fXAvWIFKEwHmDnKueWpXRaqW6chzQn0BZc1eFQ4xqiQ9gie5HV6KtKtA6 UxKkfhzfH5myg== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id A_UrusjOvJ3o; Wed, 1 Nov 2023 12:30:40 -0700 (PDT) Received: from [192.168.254.12] (unknown [47.148.192.211]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 4AB5D3C00D235; Wed, 1 Nov 2023 12:30:40 -0700 (PDT) Message-ID: Date: Wed, 1 Nov 2023 12:30:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: glibc misc/sys/cdefs.h nonull - typo in comment To: Florian Weimer Cc: Jonny Grant , Adhemerval Zanella Netto , GNU C Library , Xi Ruoyao References: <25d0b6fa-7b45-3f8e-946a-ad3256e211a4@jguk.org> <0d99df74-fb83-1647-ca19-17d2229f0ae0@linaro.org> <514c11a4-405b-f7f3-9a67-0b6c10ad7740@jguk.org> <21bc9125ab8ced26aa85f3f787f084c4af460a18.camel@xry111.site> <84e4081c-35ef-4f2d-89d0-0fea04732737@cs.ucla.edu> <87cywtvs7r.fsf@mid.deneb.enyo.de> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <87cywtvs7r.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-11-01 00:38, Florian Weimer wrote: > * Paul Eggert: > >> The April 2023 working draft of C23 has adjusted the wording to be the >> following, and I expect POSIX to follow suit eventually. Notice the new >> restrictions: >> >> "If an argument to a function has an invalid value (such as a value >> outside the domain of the function, or a pointer outside the address >> space of the program, or a null pointer, or a pointer to non-modifiable >> storage when the corresponding parameter is not const-qualified) or a >> type (after default argument promotion) not expected by a function with >> a variable number of arguments, the behavior is undefined. >> >> "If a function argument is described as being an array, the pointer >> actually passed to the function shall have a value such that all address >> computations and accesses to objects (that would be valid if the pointer >> did point to the first element of such an array) are in fact valid.... > > I'm not sure if these are new restrictions. Doesn't this make > previously undefined behavior when calling strncmp with shorter > strings defined? I don't see why. The old wording (quoted below) gives examples of invalid values that can be summarized as "A or B or C". The first paragraph of the new wording (quoted above) gives examples that can be summarized as "A or B or C or D or E". Strictly speaking the new wording is just a clarification of the old, and the "such as" in the wording means that the standard continues to be deliberately vague about exactly which function arguments are "invalid". Still, the intent is that the standardizers wanted to state clearly in the new standard that some things are undefined, even if the previous standard didn't clearly say that. Here's the old wording: "If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined." The new wording adds the following examples of invalid arguments that cause undefined behavior: * a pointer to non-modifiable storage when the corresponding parameter is not const-qualified * a type (after default argument promotion) not expected by a function with a variable number of arguments The first new example means, for example, memset ("", 0, 0) has undefined behavior. The second one means, for example, printf ("%ld", 0) has undefined behavior. As far as I can see, the changes to the standard are orthogonal to the funny business with strncmp, because strncmp's arguments are not described as being arrays of N bytes. The standard uses different wording for strncmp vs memcmp and although the wording is remarkably unclear, surely the intent is that memcmp's arguments are arrays of N bytes whereas strncmp's arguments are arrays that are at most N bytes and are null-terminated if they are shorter than N bytes.