Re: hmac-md5

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> Is there a portability requirement that 'char foo = 0xAA' end
>> up with 10101010 in the memory buffer (void*)&foo?
>
> No for C, but yes for POSIX.
>
> The main problem with char * is that, in principle, an implementation
> can dump core if you do something like "char *p; ...; *p = 128;",
> because 128 isn't a valid char value if char is signed.  I don't know
> of any practical implementations that crash, but some debugging
> implementations might, and in some sense that's a good thing.

I see.

>> I'm not sure about 'unsigned char*'.  Using 'unsigned char*' usually
>> lead to plenty of signed/unsigned warnings sooner or later.
>
> Yes, I try to avoid 'unsigned char *' for that reason'.  'unsigned
> char' is fine though.  I generally do something like this if I want to
> deal with values in the range 0 .. UCHAR_MAX:
>
>       char *p = ... compute with p ...;
>       unsigned char uc = *p;
>       ... compute with uc ...
>
> rather than use 'unsigned char *'.  It's a little more verbose but
> avoids the warnings and it's perfectly portable.  The tricy part is
> converting the unsigned char back to char.  But I'm usually lazy and
> just store it (e.g., "*p = uc"): that works on all the hosts I know
> about.

Then perhaps hmac-md5 should use 'char*'.  I really don't know the
best choice is.  I think I'll leave it as 'void*' for now, unless I
see some really good argument that 'char*' is universally better.

I'm also not sure whether we should assume POSIX in these functions.
It would be better if only C89 was assumed, I'd like for it to work on
Windows too, without portability packages such as plibc.  This also
argue for 'void*', I think.

Thanks,
Simon