From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cygnus.enyo.de (cygnus.enyo.de [79.140.189.114]) by sourceware.org (Postfix) with ESMTPS id 8108E3858D28 for ; Wed, 1 Nov 2023 20:06:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8108E3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8108E3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=79.140.189.114 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698869217; cv=none; b=H7oaop49IICL1evwWZif+bYARB8fsiCmLr36rT9kgGiJYs9Iki65UyrQB3Qu/mvalg0CHZIqXyyrRTv3+YQb4ZjEhuPnhp/CTPQQmaQZ13wvQF+9bz6/dW8LplZucWr48vMBG5wUqwQfFnZalUBhO4QaXLYeWksjv+9winoaGsA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698869217; c=relaxed/simple; bh=SzKxKiDzxRYo7Kq6pqZYWBGMU5Clr+cLvfUkR8xdv3o=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=HmS5NCgep8nmh5HuGAycFUsisaGGgq+FFpvZErJm2RQtf7lY6JA81IxA42pB9dlwpi/9nDVDWP7NIfOiME9WwFAFxsHmcmvXPVIh1PbkST6E0mHXxUu7tRhF5fRrruKjHF6RsxlN+hngkYgikzAgp9ZsE29kAp2o/uGN2gqOdK4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [172.17.203.2] (port=41575 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1qyHUL-00EVI1-Aa; Wed, 01 Nov 2023 20:06:54 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.96) (envelope-from ) id 1qyHUM-000lTa-0r; Wed, 01 Nov 2023 21:06:54 +0100 From: Florian Weimer To: Paul Eggert Cc: Jonny Grant , Adhemerval Zanella Netto , GNU C Library , Xi Ruoyao Subject: Re: glibc misc/sys/cdefs.h nonull - typo in comment 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> Date: Wed, 01 Nov 2023 21:06:54 +0100 In-Reply-To: (Paul Eggert's message of "Wed, 1 Nov 2023 12:30:39 -0700") Message-ID: <87cywttezl.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,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: * Paul Eggert: > 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". Okay, I was confused. The array part is already in C99, it seems.