[DUG] Are these good ideas?

[Jeremy Coulter]

you see my dilema ? agh....what a pain

On Wed, Nov 16, 2016 at 3:21 PM, Jolyon Direnko-Smith <jsmith at deltics.co.nz>
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 <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
>>
>
>
> _______________________________________________
> 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/38195de1/attachment-0001.html