From: Paul Eggert <eggert@cs.ucla.edu>
To: Jonny Grant <jg@jguk.org>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
GNU C Library <libc-alpha@sourceware.org>,
Xi Ruoyao <xry111@xry111.site>
Subject: Re: glibc misc/sys/cdefs.h nonull - typo in comment
Date: Sat, 28 Oct 2023 22:24:14 -0700 [thread overview]
Message-ID: <84e4081c-35ef-4f2d-89d0-0fea04732737@cs.ucla.edu> (raw)
In-Reply-To: <CAGNDjJu=B7zx26=gYOAMAsh0+ZXbYbrn+=yMd0Katw=jfifWdA@mail.gmail.com>
On 2023-10-28 16:50, Jonny Grant wrote:
> Could you give an example of a POSIX API text you refer to that
> specifies many arguments should not be NULL?
"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."
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/V2_chap02.html#tag_15_01_01
This wording is copied from the C Standard.
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.[210]
"[210] This includes, for example, passing a valid pointer that points
one-past-the-end of an array along with a size of 0, or using any valid
pointer with a size of 0."
next prev parent reply other threads:[~2023-10-29 5:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 9:09 Jonny Grant
2023-04-11 13:39 ` Adhemerval Zanella Netto
2023-04-12 15:56 ` Jonny Grant
2023-04-12 16:26 ` Xi Ruoyao
2023-04-12 16:31 ` Xi Ruoyao
2023-10-28 23:50 ` Jonny Grant
2023-10-29 5:24 ` Paul Eggert [this message]
2023-10-29 22:43 ` Jonny Grant
2023-10-30 9:04 ` Andreas Schwab
2023-10-30 10:10 ` Xi Ruoyao
2023-12-03 22:09 ` Jonny Grant
2023-11-01 7:38 ` Florian Weimer
2023-11-01 19:30 ` Paul Eggert
2023-11-01 19:52 ` Jonny Grant
2023-11-01 20:05 ` Florian Weimer
2023-11-01 20:16 ` Jonny Grant
2023-11-01 20:06 ` Florian Weimer
2023-04-12 17:28 ` Adhemerval Zanella Netto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84e4081c-35ef-4f2d-89d0-0fea04732737@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=adhemerval.zanella@linaro.org \
--cc=jg@jguk.org \
--cc=libc-alpha@sourceware.org \
--cc=xry111@xry111.site \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).