[DUG] Are these good ideas?
Jeremy Coulter
jscoulter at gmail.com
Wed Nov 16 17:43:35 NZDT 2016
HI Stefan.
You might be right. I will go and take a look....from my breif look just
now, there are a number of locations using length, so I will start taking a
look and trying your ideas.
I have started to write a "Sort Of" RESTFul service in Delphi 2007...well
it will be sudo restful in that it will respond to the verbs and accept and
pass back JSON, but it wont be restful as we are used to in new Delphi
versions :-) It should get me going in the mean time. But I will take a
crack at your idea before I get to carried away :-)
Jeremy
On Wed, Nov 16, 2016 at 5:26 PM, David O'Brien <Dave at iccs.co.nz> wrote:
> It’s a shame you can’t do:
>
> Type
>
> String = ansistring ;
>
>
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces@
> 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@
> listserver.123.net.nz <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> 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
>
>
>
> _______________________________________________
> 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/d6449c01/attachment-0001.html
More information about the Delphi
mailing list