I wasn't aware that HB_MD5 is returning a hexa string.
In my personaly opinion, but it's probably too late to modify
that, such functions should return a binary stream of bytes,
and if user wants, it can be easily converted to hex using
hb_strtohex(). This way it's properly modular and there's
no redundancy.
So instead of having an 'lbinary' option, I think this should
always return binary and no option is necessary.
At least I've been following that road with HB_SHA* functions.
Brgds,
Viktor
On Mon, Jan 19, 2009 at 10:17 PM, Przemyslaw Czerpak <dru...@acn.waw.pl>wrote:
> On Mon, 19 Jan 2009, Mindaugas Kavaliauskas wrote:
>
> Hi,
>
> > P.S. sometimes one more optional parameter would be really usefull
> > HB_{MD5|SHA1|...}( cMessage [, lBinary ] ), to avoid two unnecessary
> > Bin->Hex->Bin conversion in function like HB_HMAC:
> > FUNC HB_HMAC(fHash, cMessage, cKey, lBinary)
> > IF LEN(cKey) > 64; cKey := EVAL(fHash, cKey, .T.)
> > ENDIF
> > cKey := PADR(cKey, 64, CHR(0))
> > RETURN EVAL(fHash, HB_STRXOR(cKey, 0x5C) + ;
> > EVAL(fHash, HB_STRXOR(cKey, 0x36) + cMessage, .T.),
> > lBinary)
> > In many cases (ex., communication protocol implementation) we need binary
> > digest result, and hex format is used for human readable representation
> > only.
>
> You are right. I'll add support for such parameter.
> Maybe we should even return binary data by default.
> What's group decision?
>
> best regards,
> Przemek
> _______________________________________________
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
