you see my dilema ? agh....what a pain On Wed, Nov 16, 2016 at 3:21 PM, Jolyon Direnko-Smith <[email protected]> wrote:
> 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 <[email protected]> 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: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] with >> Subject: unsubscribe >> > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
