Jump to content
Skrim

[dcc32 Warning] uMain.pas(1154): W1058 Implicit string cast with potential data loss from 'string' to 'ShortString'

Recommended Posts

Posted (edited)

See the topic, what does this warning mean? Does it matter? If no, can I turn it off?

 

I declare a string variable like this S : string;

 

 

Edited by Skrim

Share this post


Link to post

If you hit F1 on the warning, you'll get the following explanation:

Quote

 

Emitted when the compiler detects a case were it must implicitly convert a form of Unicode (a UnicodeString or a WideString) to an AnsiString (or AnsiChar). This is a potentially lossy conversion, since there may be characters in the string that cannot be represented in the code page to which the string will be converted. This warning is on by default.

 

If you are certain that the data loss mentioned above will not happen, you can avoid this warning. To do this, cast the right operand to the left operand's type manually. Generally, avoid assigning one string type to another.

 

 

For example:

var
  s: string;
  code: string[3];
begin 
  ...
  code := s;  
  ...

Here, code is declared to be exactly 3 characters and known as ShortString; but s is declared as the default string type, Unicode. If s happens to contain 4 or more characters or happens to contain multi-byte characters, the assignment will lose data. The compiler is warning you about this possibility.

 

Yes, you can turn off this warning (in Project Options > Delphi Compiler > Hints and Warnings) but I would not recommend it as unforeseen bugs can more easily creep into your code. The except might be temporarily considered when inheriting an old project that has been working for years and compiling generates thousands of hints and warnings and you just want to turn down the noise until you can get the project under control.

Share this post


Link to post
Posted (edited)
1 hour ago, corneliusdavid said:

If you hit F1 on the warning, you'll get the following explanation:

LOL, I have been using Delphi since version 2 and I did not know that :classic_blush:

 

I always declare string as aString : string; never aString : string[3]; But a lot of these string values are saved to a database field declared in the database as a string with a fixed length, could that be the reason for the error?

 

Kind regards

Edited by Skrim

Share this post


Link to post
4 minutes ago, Skrim said:

LOL, I have been using Delphi since version 2 and I did not know that

Yeah, lots of hidden gems have been added over the years. I don't always read everything in the "What's New" section and also occasionally discover features that have been there for a while!

6 minutes ago, Skrim said:

But a lot of these string values are saved to a database field declared in the database as a string with a fixed length, could that be the reason for the error?

It wouldn't be the underlying database structure but how they're accessed. I often get this type of warning when upgrading old applications (Delphi 5/7/2007) to newer versions where string fields were assigned like this:

procedure UpdateValues(const NewValue: string);
begin
  MyTable.StrField.Value := NewValue;
  ...

The .Value property is AnsiString; simply changing it to use the explicit type eliminates the warning:

procedure UpdateValues(const NewValue: string);
begin
  MyTable.StrField.AsString := NewValue;
  ...

 

  • Thanks 1

Share this post


Link to post
3 hours ago, David Heffernan said:

Is there a reason to use shortstrings?

Not sure who you're asking. Skrim didn't say he was using shortstring. I put that in the first example as a way to generate the error he saw--but no, I never use them in new code. When I use MyField.Value (as in my second reply), the warning lists "AnsiString" instead of "ShortString" which is what led me to write what I did in the first suggestion, not knowing what code he was dealing with.

Share this post


Link to post
8 hours ago, corneliusdavid said:

Not sure who you're asking. Skrim didn't say he was using shortstring. I put that in the first example as a way to generate the error he saw--but no, I never use them in new code. When I use MyField.Value (as in my second reply), the warning lists "AnsiString" instead of "ShortString" which is what led me to write what I did in the first suggestion, not knowing what code he was dealing with.

Clearly the OP is using short string because the compiler says so. My question is to the OP. Why use short string? 

Share this post


Link to post
On 10/6/2024 at 9:07 PM, David Heffernan said:

Is there a reason to use shortstrings? It's 2024 now.... 

Yes, sometimes it is necessary, especially in connection with RS232 data transfers, for example. Some of the devices that still have an RS232 are really quite old.

Share this post


Link to post
2 hours ago, gkobler said:

Yes, sometimes it is necessary, especially in connection with RS232 data transfers, for example.

Um.. RS232 is a hardware standard.

Share this post


Link to post
6 minutes ago, Anders Melander said:

Um.. RS232 is a hardware standard.

I mean a communication over a ComPort via RS232 😉

Share this post


Link to post
1 minute ago, gkobler said:

communication over a ComPort via RS232

It's still hardware and nothing in the various software APIs require the use of shortstring.

Share this post


Link to post
5 hours ago, gkobler said:

Yes, sometimes it is necessary, especially in connection with RS232 data transfers, for example. Some of the devices that still have an RS232 are really quite old.

I'd definitely not be using Shortstring for that.

 

But the asker has talked about the usage being for database. So RS232 not pertinent. 

Edited by David Heffernan

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×