[DUG] Are these good ideas?

[David O'Brien]

It’s a shame you can’t do:
Type
  String = ansistring ;


From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Stefan Mueller
Sent: Wednesday, 16 November 2016 4:48 pm
To: 'NZ Borland Developers Group - Delphi List' <delphi at listserver.123.net.nz>
Subject: Re: [DUG] Are these good ideas?

Search your code for “length()” function –the length function on an ansistring has returned the size in bytes (8bit), now it returns the size in words (16bit). Places where you write strings to files and streams are usually places that need a fix. Do that search and you should probably have like 99% of your unicode issues found. Switching over to Unicode isn’t that big of a drama.


As for the MD5 issue – there’s actually a bit more to it – you can easily fix it by typecasting to ansistring and you should then get the same md5 hashes back again like in older pre-unicode Delphi versions:

function foo(s: String): Integer;
   var
      s2: AnsiString;
   begin
      s2 := AnsiString(s);   //typecasting to ansistring without getting compiler warnings
      Result := md5(@s2[1], length(s2));
   End;


…but the question is if you really want to keep limiting yourself to ansistring? Now that your program will be unicode enabled you might as well embrace it fully and for example make your code work with chinese passwords too:

function foo(s: String): Integer;
   var
      data: TBytes;
   begin
     data := TEncoding.UTF8.GetBytes(s);
      Result := md5(data, length(data));
   End;




Kind regards,
Stefan Müller,
R&D Manager

ORCL Toolbox Ltd.
Auckland, New Zealand

P Please consider the environment before printing this email

This message is intended for the adresse named above and may contain privileged or confidential information.
If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone.

From: delphi-bounces at listserver.123.net.nz<mailto:delphi-bounces at listserver.123.net.nz> [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jeremy Coulter
Sent: Wednesday, 16 November 2016 3:34 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Are these good ideas?

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<mailto: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<mailto: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<mailto: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<mailto:delphi-request at listserver.123.net.nz> with Subject: unsubscribe


_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz<mailto: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<mailto: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/3fe170ba/attachment-0001.html