Blog: Byte Loss in String-Literal Concatenation

[baoquan.zuo 35]

Hi,

 

I'd like to share a post. It addressed a byte loss issue captured from a discussion.

// Compile with code page 936
program Problem;

const
  strPublicKey: RawByteString =
    #$30#$3C#$30#$0D#$06#$09#$2A#$86#$48#$86#$F7#$0D#$01#$01#$01#$05 +
    #$00#$03#$2B#$00#$30#$28#$02#$21#$00#$A4#$65#$B8#$CD#$B4#$29#$A9 +
    #$64#$1A#$C5#$80#$55#$22#$1B#$BB#$C5#$98#$36#$B9#$23#$0C#$CA#$D4 +
    #$A8#$B8#$7C#$E6#$32#$E3#$89#$3D#$77#$02#$03#$01#$00#$01;
begin
  Writeln(Length(strPublicKey)); // expected 62 got 58 - why?
  Readln;
end.

https://devjetsoftware.com/delphi/byte-loss-in-string-literal-concatenation/

[David Heffernan 2421]

What is wrong with the world of Delphi programmers that in 2025 there are still people who can't understand the difference between text and bytes? 

 

The article you link to goes on and on about text but your data is bytes. Why not just use the correct data type? 

[baoquan.zuo 35]

2 minutes ago, David Heffernan said:

What is wrong with the world of Delphi programmers that in 2025 there are still people who can't understand the difference between text and bytes? 

 

The article you link to goes on and on about text but your data is bytes. Why not just use the correct data type? 

Yes — it’s clear we should use the proper data type to represent raw bytes.

 

What the article (and my curiosity) really digs into is why the data loss occurs and how DCC handles string literals (as there is no formal Delphi language specification). That matters to me because I’m also writing some Delphi compiler-frontend code in my products.

 

In any case, these insights should help when migrating legacy ANSI-based Delphi projects.

[David Heffernan 2421]

5 minutes ago, baoquan.zuo said:

In any case, these insights should help when migrating legacy ANSI-based Delphi projects

I don't see this as helpful to anyone. Use bytes to represent bytes. Use strings to represent text. Don't use ANSI strings. 

[baoquan.zuo 35]

13 minutes ago, David Heffernan said:

I don't see this as helpful to anyone. Use bytes to represent bytes. Use strings to represent text. Don't use ANSI strings. 

Thanks for sharing your view.

[Roger Cigol 130]

Of course there ARE times when the use of ANSI strings makes sense. One example is when sending data to/from an external device down an RS232 port where the external device uses a protocol based on simple ANSI text. We have many real world cases such as this (eg Eurotherm temperature controllers). The key point that @David Heffernan makes is that you should choose your types carefully to closely (or exactly!) reflect your needs. Time spent thinking carefully about your type selection will save you time in the long run.....

[David Heffernan 2421]

2 hours ago, Roger Cigol said:

Of course there ARE times when the use of ANSI strings makes sense. One example is when sending data to/from an external device down an RS232 port where the external device uses a protocol based on simple ANSI text. We have many real world cases such as this (eg Eurotherm temperature controllers). The key point that @David Heffernan makes is that you should choose your types carefully to closely (or exactly!) reflect your needs. Time spent thinking carefully about your type selection will save you time in the long run.....

I mean, you work with strings and do TEncoding.ASCII.GetBytes

[Roger Cigol 130]

20 minutes ago, David Heffernan said:

I mean, you work with strings and do TEncoding.ASCII.GetBytes

All good ! There is more than one way to skin a cat.....