Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2012-02

Warning: Implicit string type conversion

5 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Hans-Peter Diettrich

I wonder how these many messages occur, even in building the libraries. Is it only lazyness why according fixes are missing, or are there reasons why such conversions are inevitable?

Dumb question: what's the default "string" type in FPC trunk? When it's AnsiString, in which situations are UnicodeString conversions really required, in contrast to pre-UnicodeString versions?

What about WideString? E.g. fcl-xml contains a lot of WideString types - shouldn't these be replaced by (or retyped into) UnicodeString now? IMO only the Windows COM libraries require real WideString (BSTR) arguments, while the ordinary "W" API should be happy with pointers to UnicodeStrings.

DoDi

Reply by email

Paul Ishenin
to Hans-Peter Diettrich

02.02.2012 17:00, Hans-Peter Diettrich пишет:

I wonder how these many messages occur, even in building the libraries. Is it only lazyness why according fixes are missing, or are there reasons why such conversions are inevitable?

Compiler informs that there are places which has suspicious code. Probably the code there needs a review.

Dumb question: what's the default "string" type in FPC trunk? When it's AnsiString, in which situations are UnicodeString conversions really required, in contrast to pre-UnicodeString versions?

The default string type is ShortString/AnsiString and this depends on {$h+/-} option. UnicodeString convertions are required when string in one codepage is converted to another or when ansistring is assigned to unicode/wide string type.

What about WideString? E.g. fcl-xml contains a lot of WideString types - shouldn't these be replaced by (or retyped into) UnicodeString now? IMO only the Windows COM libraries require real WideString (BSTR) arguments, while the ordinary "W" API should be happy with pointers to UnicodeStrings.

I agree that better to review fcl-xml code and at least replace WideStrings with UnicodeStrings.

Best regards,
Paul Ishenin.

Reply by email

Hans-Peter Diettrich
to Paul Ishenin
Show quoted text 8 lines
02.02.2012 17:00, Hans-Peter Diettrich пишет: > Dumb question: what's the default "string" type in FPC trunk? When it's > AnsiString, in which situations are UnicodeString conversions really > required, in contrast to pre-UnicodeString versions? The default string type is ShortString/AnsiString and this depends on {$h+/-} option.

What's the codepage/encoding of AnsiString? Depending on the platform?

UnicodeString convertions are required when string in one codepage is converted to another or when ansistring is assigned to unicode/wide string type.

In many places I could not find strings of different encoding nor unicode/widestrings. That's why I asked for other reasons, which in pre-Unicode FPC didn't require any conversion - in these cases it had been necessary to convert the strings explicitly, what should be obvious in the (old) source code.

Can char or string literals or resource strings cause implicit conversions? What's the encoding of resource strings?

DoDi

Reply by email

Marco van de Voort
to Hans-Peter Diettrich

In our previous episode, Hans-Peter Diettrich said:

Show quoted text 7 lines
>> AnsiString, in which situations are UnicodeString conversions really >> required, in contrast to pre-UnicodeString versions? > > The default string type is ShortString/AnsiString and this depends on > {$h+/-} option. What's the codepage/encoding of AnsiString? Depending on the platform?

The default (one-byte) codepage on the system.

Reply by email

Paul Ishenin
to Hans-Peter Diettrich: What's the codepage/encoding of AnsiString? Depending on the platform? In many places I…

02.02.12 19:51, Hans-Peter Diettrich пишет:

What's the codepage/encoding of AnsiString? Depending on the platform?

DefaultSystemCodePage - this const depends on platform

Show quoted text 12 lines
> UnicodeString convertions are required when string in one codepage is > converted to another or when ansistring is assigned to unicode/wide > string type. In many places I could not find strings of different encoding nor unicode/widestrings. That's why I asked for other reasons, which in pre-Unicode FPC didn't require any conversion - in these cases it had been necessary to convert the strings explicitly, what should be obvious in the (old) source code. Can char or string literals or resource strings cause implicit conversions?

Not themself but operations with them.

What's the encoding of resource strings?
They are still ansistring with compiler codepage (defined by -Fc or
{$codepage}).

In Delphi resourcestrings are unicodestrings but this is not so in FPC because team still not decided about the default string type.

Best regards,
Paul Ishenin.

Reply by email