hmmm, really strange. In this case I won't add any SHA2 functions to core in
this fashion. Rather I'll keep it in hbcrypt() in binary form.
Or, if group agrees, we break with the HB_MD5 "habit" and these
new ones will use binary data by default.
Am I living a different world, or is it true, that in the majority of cases
checksums are meant to be printed for _users_? I would think these
cryptic numbers are most of the time embedded in some streams,
and a machine is dealing with them. Except when it's travelling in
a text file (.xml, .ini, and oh well .sfv).
To me the latter seems by far the rarest, but again I may be wrong.
But even if so, it's just a function call to convert vice and versa.
Anyhow it'd be nice the know what led to the current MD5
implementation.
Brgds.
Viktor
On Mon, Jan 19, 2009 at 10:23 PM, Mindaugas Kavaliauskas <dbto...@dbtopas.lt
> wrote:
> Hi,
>
> 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?
>>
>
> No, let's leave it default to hex format. Hackers will be clever enough to
> add .T., the other, ex., who just want to print md5 sum of a file, will be
> glad to do:
> ? hb_md5file("myfile.ext")
>
> Leaving lBinary = .F. for default will also make this change backward
> compatible.
>
> For example PHP uses also this convention:
> string md5( string str [, bool raw_output] )
> raw_output is false by default.
>
>
> Regards,
> Mindaugas
>
>
> _______________________________________________
> 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
