[DUG] Are these good ideas?
Jolyon Direnko-Smith
jsmith at deltics.co.nz
Wed Nov 16 15:21:20 NZDT 2016
If by your "code that is working" (vs code that isn't) refers to the two
different methods being used to produce an MD5 Hash, then I think there is
a bit of confusion about the problem (hard to say without actual code).
i.e. it is possible that *both* of your MD5 implementations are working
absolutely correctly. The problem is the way that your data is being
passed in/out. MD5 is not a string-specific hashing algorithm - it works
on bytes, not characters (otherwise you couldn't produce an MD5 digest for
a binary file, for example).
e.g. if you have a function that accepts a string but then treats it as a
pointer to some bytes (which is what a "string" is, after all) and assumes
that the memory referenced by that pointer occupies the number of bytes
indicated by the length of the string:
function Foo(aString: String): Integer;
var
i: Integer;
ptr: PByte;
len: Integer;
begin
len := Length(aString);
ptr := PByte(aString);
for i := 1 to len do
begin
// Do something with each byte then move on to the next one...
Inc(ptr);
end;
// blah blah
end;
This works perfectly well for an ANSI String because an ANSI String is a
sequence of ANSIChar and an ANSIChar is a single byte. But this code will
compile without any warning on Delphi 2009 and later, where "String" is now
synonymous with a "UnicodeString" which is a sequence of WIDEChars. i.e. 2
bytes. But even without ANY warning or hints that anything is amiss, the
function will now process only HALF the string that it is passed (and half
of the bytes it does process will themselves be 0 [zero] - i.e. nulls).
When migrating string handling code from ANSI to Unicode strings, you have
to look for these sorts of issues as well as intermixed ANSI and WIDE
types. I suspect that this is what is going on in your case.
The above function could be "fixed" by correcting the declaration to
explicitly accept an ANSIString:
function Foo(aString: ANSIString): Integer;
Now the assumption in the implementation that each char is 1 byte will be
correct, but you will start seeing warnings about possible data loss
resulting from any implicit conversions from Unicode to ANSI Strings.
NOTE: In the case of an MD5 hash, fixing the implementation to process
UnicodeStrings correctly (processing all bytes in the string by process 2 x
LENGTH bytes of the string) will not result in the same MD5 hash because
MD5 works on bytes, not chars. An ANSIString and it's Unicode equivalent
may be visually "equal" when displayed, but the binary representation of
them is different and so the MD5 digest will also be different.
If the binary representation is significant to your algorithm (as it is
with MD5) then what you really need is TWO versions of the above function.
One for ANSIString (working on the basis of 1 byte per char) and a separate
implementation for UnicodeString (2 bytes per char).
You then need to make sure that you correctly convert to and pass strings
in the appropriate encoding to each function as and when required.
On 16 November 2016 at 13:30, Jeremy Coulter <jscoulter at gmail.com> wrote:
> Hi Again.I am looking at a Plan B to my last email about converting some
> code.
>
> What I am thinking is, I COULD just use the code I have that is working,
> and may be create a DLL and access it from my new application.
> However, the code is actually running a server that listens on a couple of
> ports and when "things" happen, it fires an event that is then captured by
> an event on the front end.
> Can I run a service as above in a DLL and have events that I guess just do
> a pass through to the DLL calling application?
>
> The other thought I had was to write a COM DLL, but bit wary of that.
>
> Anyone got any thoughts on the above?
>
> Thanks, Jeremy
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20161116/2a2e1dff/attachment.html
More information about the Delphi
mailing list