This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] sha2: new header <sha2.h>
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: shawn at churchofgit dot com, libc-alpha at sourceware dot org
- Date: Thu, 2 Apr 2015 11:17:28 -0400
- Subject: Re: [PATCH] sha2: new header <sha2.h>
- Authentication-results: sourceware.org; auth=none
- References: <1427529610-3508728-1-git-send-email-shawn at churchofgit dot com> <551C6FA4 dot 5030603 at redhat dot com> <20150402004334 dot GR6817 at brightrain dot aerifal dot cx> <551CF719 dot 6040904 at redhat dot com>
On Thu, Apr 02, 2015 at 10:00:25AM +0200, Florian Weimer wrote:
> On 04/02/2015 02:43 AM, Rich Felker wrote:
>
> > I'm opposed to allocation/deallocation functions. They have no benefit
>
> They have the benefit that the library can ensure the required
> alignment, instead of the caller having to provide it.
Then just make the caller-provided buffer twice the size it "should"
be. Then the callee can use the actual embedded buffer it with any
alignment it wants.
> There might be hardware implementations which require additional
> alignment, to the degree that it cannot be satisfied with the current
> spare space in the buffer.
>
> The non-opaque struct also gives the impression you can copy the struct
> to implement HMACs, or that the struct contents is portable across
> process invocations, which is something we should not promise.
There's no reason to give that impression. The contents can be clearly
opaque, e.g.:
long __opaque[NNN];
> > Allocation also means you
> > can't use it in an async signal context.
>
> As far as I can tell, the functions have not been proposed as
> async-signal-safe, so this does not matter.
I agree this is a less important matter than breaking the no-fail
contract users will want/need, but I thought it was noteworthy still.
Rich