public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: newlib@sourceware.org
Subject: Re: [PATCH] Reimplement aligned_alloc
Date: Fri, 22 May 2020 16:22:35 +0100	[thread overview]
Message-ID: <20200522152235.GB24880@arm.com> (raw)
In-Reply-To: <b0793ffd-034d-4b4f-446c-c50c44f63b2d@SystematicSw.ab.ca>

The 05/20/2020 08:32, Brian Inglis wrote:
> >> On 19/05/2020 11:52, Szabolcs Nagy wrote:
> >>> - Failed to set errno on error.
> 
> > The 05/19/2020 19:41, Sebastian Huber wrote:
> >> why should aligned_alloc() set errno on error?
> 
> On 2020-05-20 02:54, Szabolcs Nagy wrote:
> > iso c allows standard api calls to set errno
> > (except not to 0) but usually does not specify
> > error conditions, however posix does and
> > requires allocation functions to set errno
> > to ENOMEM on failure.
> > 
> > posix is not yet aligned with c11 so there is
> > no errno specification for aligned_alloc but
> > that does not mean newlib should make it
> > deliberately inconsistent with other allocation
> > functions, users will try to use perror or
> > strerror when calls fail that may internally
> > use aligned_alloc and expect reasonable error
> > message.
> 
> IEC 9899-2011[2012] specifies no errno values for any of the 7.22.3 Memory
> management functions, and under Annex J.1 Unspecified behaviour and J.2
> Undefined behaviour, omits aligned_alloc from issues of related functions, but
> under J.2 specifies as a portability issue only:
> 
> -- The alignment requested of the aligned_alloc function is not valid or not
> supported by the implementation, or the size requested is not an integral
> multiple of the alignment (7.22.3.1).
> 
> POSIX posix_memalign specifies errno = EINVAL for this case and errno = ENOMEM
> for the OoM case.
> 
> It seems more useful to set errno to POSIX compatible values when returning a
> NULL pointer than attempt nasal demon emission.

note that posix_memalign does not set errno,
but returns an error value.

in principle aligned_alloc could check its
alignement argument too and set errno to
EINVAL, but to me that case seems less
important in practice: it's not a dynamic
runtime failure like running out of memory,
but wrong argument bug in user code that
should be fixed statically instead of
checking errno.

if posix is updated to cover aligned_alloc
and requires EINVAL for this case, then
newlib can be updated.

      reply	other threads:[~2020-05-22 15:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  9:52 Szabolcs Nagy
2020-05-19 13:24 ` Corinna Vinschen
2020-05-19 17:41 ` Sebastian Huber
2020-05-19 21:02   ` Joel Sherrill
2020-05-20  8:54   ` Szabolcs Nagy
2020-05-20 14:32     ` Brian Inglis
2020-05-22 15:22       ` Szabolcs Nagy [this message]

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=20200522152235.GB24880@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=newlib@sourceware.org \
    /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).