On Thu, Oct 05, 2017 at 05:12:07AM +, Taylor R Campbell wrote:
> > 3. Going forward, create a new crypthash.h, and have it include all
> > the hash function headers (hmac.h, md5.h, sha1.h, rmd160.h, etc etc)
> > and document all the latter as deprecated. That is, going forward the
> > offic
On 05/10/2017 06:12, Taylor R Campbell wrote:
>> Date: Thu, 5 Oct 2017 04:34:08 +
>> From: David Holland
>>
>> 3. Going forward, create a new crypthash.h, and have it include all
>> the hash function headers (hmac.h, md5.h, sha1.h, rmd160.h, etc etc)
>> and document all the latter as deprecate
On 05/10/2017 05:34, David Holland wrote:
> After some discussion on irc today the following tentative plan's been
> floated for addressing hmac(3):
>
> 1. Give it its own hmac.h; this is consistent with the way each hash
> function currently has its own header file. Rem
If multiple header files is leading to redundant code, I’d certainly prefer
a single header file. After all redundancy is a bad thing inside a
database, but we can have multiple copies of the database stored at
multiple locations on a distributed network (which I’m quite sure is
already the case, w
> Date: Thu, 5 Oct 2017 04:34:08 +
> From: David Holland
>
> 3. Going forward, create a new crypthash.h, and have it include all
> the hash function headers (hmac.h, md5.h, sha1.h, rmd160.h, etc etc)
> and document all the latter as deprecated. That is, going forward the
> official interface
After some discussion on irc today the following tentative plan's been
floated for addressing hmac(3):
1. Give it its own hmac.h; this is consistent with the way each hash
function currently has its own header file. Remove it from stdlib.h,
where it causes name conflicts and namespace poll
Kamil Rytarowski wrote:
>On 29.09.2017 13:59, Robert Swindells wrote:
>>
>> Does hmac(3) really belong in stdlib.h ?
>>
>> I'm getting a conflict with something that defines its own hmac()
>> function and also includes stdlib.h.
>
>We usually rename
On 29.09.2017 13:59, Robert Swindells wrote:
>
> Does hmac(3) really belong in stdlib.h ?
>
> I'm getting a conflict with something that defines its own hmac()
> function and also includes stdlib.h.
>
We usually rename 3rd party hmac to something like my_hmac or simi
> Date: Fri, 29 Sep 2017 12:59:11 +0100
> From: Robert Swindells
>
> Does hmac(3) really belong in stdlib.h ?
>
> I'm getting a conflict with something that defines its own hmac()
> function and also includes stdlib.h.
No, not really.
You can avoid this by defining
Does hmac(3) really belong in stdlib.h ?
I'm getting a conflict with something that defines its own hmac()
function and also includes stdlib.h.
Robert Swindells
10 matches
Mail list logo
