From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id EA5B33858D28 for ; Wed, 1 Nov 2023 19:52:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EA5B33858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EA5B33858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::236 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698868390; cv=none; b=vFvyj0XWyg1QbdVnPGiomV9gx+XldVgD89HXcNwXe7eTSBnObKdeT0eh4dpr/ZPyuhuWNx++QvFMRaFHfQF9NzD5FLQ7dTQdiWvGYvKAzEa9ZHeqZuqFxjTZ7gSQFZwmNV6TJcXi3VxFSQT23RCMNw3SsCIU61SSNtom5BLJqcs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698868390; c=relaxed/simple; bh=54i1aJSiUEUBIsu7Y4YaVsFSHbkb2Fk2Et8YGf7JfaU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=WDII9+aw9YTGNs2Os6eZiLKmDLEr9Th/UDsxw0ihX3PgdAffctkFyFiPyKRTdK1kAmtXziRZb6S3Zm0svS79fW5Yj9hBiWqAiMKkEgwReBVNyDDZqrOtzzLENmmgGGNiqOuHakBQh6oMb2++4eh2hUEoF4+Vw5PPyO+0o6GkK6A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2c503da4fd6so2314521fa.1 for ; Wed, 01 Nov 2023 12:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; t=1698868378; x=1699473178; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4V3aj6omTm6AXYceCKNM5tMG2vkxaincKI40tML5A38=; b=duY3HleyfoVL6BczXuuNw3weDYPW+1RpnwTNRbiNnfnwjfaA4rQNlM4kMGYlL7GgEZ 10bIHzfPdeEhDSgoSIhuYl+C8F7Gvk9luGxhbcdFOVXi7MyRqglXbMPepnpz89rwBb/6 XPoENrou1DSDzLEbVw4rwYwZu7vlh4iX2O0tl4JW9r1JNa/MlIQxZQ0j8MEPEBnCug5p Jb4dETiYJ/gUM5lNWpmjLQgAM7sUwk33l72q5fwp6OEj7TKOByQMlzJZISMDfgpoybXQ pZjjEf9smEANR6oe/8x5IEQA4Hl3U/L8VF4edts2nUuyunqhQ3oySJoQuci4OIab0PxC U02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698868378; x=1699473178; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4V3aj6omTm6AXYceCKNM5tMG2vkxaincKI40tML5A38=; b=uRei4Lsb11w7EUVlD1q5HJeInaqTCDDemfWm3Nba0VfXnMz+toBN0r3lDeAkXolgFV hdkIcY5BKeoQv6KpmRXm1mZa3Cg8INfUZrQc2j8KSovNuyAHVaMZMqdXO9PARkCFtNDx BTOgBRqoe+JCxBNjWBIVMuu1K/soOVnxxTCX6Zpy6QLGTB5SAlAh6m7TMSje2P0ZdVaX P+mRWehjM+syjeqfGoauJ2bcp0EPDvYrefmohQI+eDTCayT7tJhFL6/4o7a4UayV2l1s Y0kaq1d2Ud0WU5nLCB2RN6p6ydLldfQd7pJ/qTbpMj0LM+S0McbvwUruQPdsPPpgi22Z VOTA== X-Gm-Message-State: AOJu0YzQo89mViKJltV45Kn3belEXiU41rSOwlPKXoNHd8i9kjpC/9BX 4/EQyOeNAnN1zYN9hGeWvuXpbkEXv0Ieom5uBtw= X-Google-Smtp-Source: AGHT+IHCvEDufLxtvvswN2nDv+ClUMgSLVtJreD45QDGeZZdkzDp76umz9ZjHZXN8GhSrJhX0gqI6g== X-Received: by 2002:a05:651c:c9b:b0:2c0:7d6:570a with SMTP id bz27-20020a05651c0c9b00b002c007d6570amr15459104ljb.33.1698868378301; Wed, 01 Nov 2023 12:52:58 -0700 (PDT) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id m3-20020a05600c4f4300b0040531f5c51asm587266wmq.5.2023.11.01.12.52.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Nov 2023 12:52:57 -0700 (PDT) Message-ID: <739d8f2c-af88-46b5-ac83-76392640753c@jguk.org> Date: Wed, 1 Nov 2023 19:52:57 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: glibc misc/sys/cdefs.h nonull - typo in comment Content-Language: en-GB To: Paul Eggert , Florian Weimer Cc: 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> From: Jonny Grant In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,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 01/11/2023 19:30, Paul Eggert wrote: > 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. As I read it, the C standard wording doesn't make it 100% clear for readers that strcmp or strncmp will stop comparing when it reads a null terminating byte, in either, or both strings. It is probably implied from other description of C strings in the standard. Perhaps the standard could be clarified. Jonny