From: Joseph Myers <joseph@codesourcery.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: <libc-alpha@sourceware.org>
Subject: Re: [PATCH] crypt: Use internal names for the SHA-2 block functions
Date: Fri, 28 Oct 2016 18:07:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1610281759240.24570@digraph.polyomino.org.uk> (raw)
In-Reply-To: <49a0f49e-b22c-2dd1-fa5b-bbad89e8aacb@linaro.org>
On Fri, 28 Oct 2016, Adhemerval Zanella wrote:
> > It's true that linknamespace considerations apply even for _DEFAULT_SOURCE
> > and _GNU_SOURCE - using a function declared under one of those conditions
> > should not bring in a reference to a function not so declared. The
> > difficulty in testing this is that it really needs a list of all installed
> > headers to be visible in one place (and there's the question of whether we
> > consider _DEFAULT_SOURCE to include all headers or not).
>
> Right, but how hard would to add a rule in conform to tests for glibc specific
> headers (conformtest-headers-GLIBC or conformtest-headers-GNU) and at
> first add the crypt.h plus _GNU_SOURCE?
You'd need the set of headers for linknamespace tests to be bigger than
the set for conformtest tests (which makes sense anyway - there are
several standard variants without conformtest expectations, setting up
such expectations is a lot of work, but listing headers in a standard is
easy and listing headers plus specifying compilation options is all that's
needed for linknamespace tests).
But you'd have to hope that the set of headers you specify for _GNU_SOURCE
is internally consistent. It's perfectly valid under our namespace rules
for a <crypt.h> function to call a function in some Linux-specific header,
for example (and the Linux-specific headers can't be listed in
conform/Makefile, only sysdeps/unix/sysv/linux/Makefile knows about them).
I wonder about arranging the makefiles so they record each subdirectory's
list of installed headers as part of the build, the toplevel collects that
information together, so when the testsuite runs such a list is available.
Running tests in each subdirectory works for e.g. Zack's tests, where
testing for each header is independent, but not for things that need to
see a complete list of all installed headers at once. That way, conform/
could access that list saved during the build, and filter out bits/
headers (and any other headers that just give errors, like Zack's tests
filter out some such headers) to get a list of headers for GNU / DEFAULT
linknamespace tests.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2016-10-28 18:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-28 12:57 Florian Weimer
2016-10-28 13:32 ` Adhemerval Zanella
2016-10-28 17:09 ` Joseph Myers
2016-10-28 17:57 ` Adhemerval Zanella
2016-10-28 18:07 ` Joseph Myers [this message]
2016-10-28 20:05 ` Florian Weimer
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=alpine.DEB.2.20.1610281759240.24570@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@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).