procedure getchars( p : pchar );
var l : longint;
begin
 l := length( p );
end;

If calling getchars with chars longer than 255 l is always 255.

For example:
getchars( '12345 ... 255256257258' +
'1234567213939873987' +
...
...

                '1234567213939873987');  // more than 255 chars

Version 2-4-2.0

With other Versions before 2-4-2.0 it was ok (more chars than 255 possible). It seems that this is a bug.
May be it is resolved already.

It works when {$LONGSTRINGS ON} or {$H+} directive exists. I think the compiler treats functions receiving array of char (or pointer to it) as ShortString when none of the directives above exist.

leledumbo wrote

It works when {$LONGSTRINGS ON} or {$H+} directive exists. I think the compiler treats functions receiving array of char (or pointer to it) as ShortString when none of the directives above exist.

No it does not work then.
I put already the -Sh- additional compiler arg.

For me it seems like a bug, because in the previous version of FPC (2-2-4.3) it works. It seems that the compiler now cuts every constant string in the sourcecode to 255 characters.

leledumbo wrote

I think the compiler treats functions receiving array of char (or pointer to it) as ShortString when none of the directives above exist.

Indeed, FPC defaults to ShortString if {$H+} is not specified. That is probably the problem. I really don't know why this is still so (maybe some performance thing inside the compiler itself). I now simply specify $H+ in the fpc.cfg file, in case I forget to add it to the header of a unit.

-Sh- Is the same as {$h-} or {$longstrings off}. You need -Sh (provided that there's no {$mode fpc/objfpc/tp/macpas} in the source file, since that will disable them again).

Jonas

You cannot do length in a PChar, it has no length information. I think this code is probably automatically converting the PChar to a Pascal String and then after that calling Length in the Pascal String, so your code is not very efficient.

Pass the length of the PChar in an aditional parameter instead. Or write a routine which will count until the first #0 of the PChar to see how many characters it has.

That the compiler uses ShortString for performance reasons is not related to the fact that ObjFPC uses them by default. In this case the reason is simply backwards compatibilty (note: not Delphi compatibilty :P ). Though its not the compiler which is the problem here as it has an explicit "{$H-}" in its define include file.

Regards,
Sven

Sven Barth wrote

In this case the reason is simply backwards compatibilty (note: not Delphi compatibilty :P ).

But that's my point. I really don't think anybody is writing TP style programs any more. So wouldn't it make sense to change the default for the vast majority or programs written with FPC today? Mode TP (-Mtp) can default to shortstring and mode Delphi or mode ObjFPC can default to longstrings?

Just like I think FPC should default to mode ObjFPC (instead of mode fpc). Though I must admit, I have no idea what the difference are between those modes.

The backwards compatibilty in this case is not for TP, but for FPC code that uses ObjFPC, but not H+.

In the end you need to discuss this with Florian, Jonas or some other senior dev who has the final say for this...

Note: mode Delphi already defaults to H+

Just like I think FPC should default to mode ObjFPC (instead of mode fpc). Though I must admit, I have no idea what the difference are between those modes.

No classes, no try/except/finally and some other things maybe

Regards,
Sven

length(pchar) is translated into strlen(pchar) (just like in Delphi).

Jonas

With {$h+} it works.

But when having pchar I wonder why it generally is not possible to make strings longer than 255 as it was possible in the previous compiler version.

For shortsting I accept strings not longer than 255 chars.

Why is it not possible to make a var like
svar : shortstring[ 20 ] ?

The whole program I made is compiled with {$h-} so it would be much fault-prone work to put everywhere {$h+} and then {$h-} again.

Maybe not an answer to your question, but why do you use length?

As mentioned before by someone else: length does read a field from the string, which does not exist in pchar (hence string can contain #0 and pchar can not).

So why not use pos(#0, foo_pchar) ?

Of course this does not answer the question IF or WHY this has changed

Because the definition of the type 'ShortString':

   ShortString = String[255];

is somewhere in the ObjPas or system unit.

If the compiler finds a size after the 'String' keyword, it automatically assumes a "shortstring" (by this I mean the compiler internal's idea of "shortstring").

The definition of 'Shortstring' as shown above is just an aid, for Delphi compatibility.

Michael.

Martin wrote

As mentioned before by someone else: length does read a field from the string, which does not exist in pchar (hence string can contain #0 and pchar can not).

Jonas mentioned in another mail in this thread (as an answer to Felipe) that "Length(PChar)" is converted to "StrLen(PChar)" which is Delphi compatible.

Regards,
Sven

Martin wrote

As mentioned before by someone else: length does read a field from the string, which does not exist in pchar (hence string can contain #0 and pchar can not).

Ok, before someone comments on this:

pchar can contain #0

but for automatic string conversation the 0 has special meaning

Martin wrote

So why not use pos(#0, foo_pchar) ?

That will convert foo_pchar to a string type (which one probably depends on the state of the {$h} switch) and then call pos() on it. Again: length(pchar) is perfectly correct and will be translated into strlen(pchar), just like in Delphi (and probably even like in TP).

Jonas

Jonas Maebe wrote

length(pchar) is translated into strlen(pchar) (just like in Delphi).

But why is it limited to 255 chars in {$H-} ? (I understood that it is limited like this from the original poster)

I don't see anything about this in the docs:

http://www.freepascal.org/docs-html/rtl/strings/strlen.html

Rainer Stratmann wrote

But when having pchar I wonder why it generally is not possible to make strings longer than 255 as it was possible in the previous compiler version.

There was never a change regarding this as far as I know.

Because the correct declaration is

svar: String[20];

This will give you a string with maximum length 20 (the maximum available length for a declaration like this is 255 which is equal to ShortString).

Regards,
Sven

If you look at the call the original poster sent, you will see why:

FPC converts the constant string to the current generic string type which is String[255] in case of {$H-} and not AnsiString. Thus the string will appear truncated after 255 characters.

Regards,
Sven

There is one change about this in 2.6.0: http://wiki.freepascal.org/User_Changes_2.6.0#String_constants_longer_than_255_chars

Jonas

It is not.

(I understood that it is limited like this from the original poster)

The original poster said that he could not use string constants longer than 255 characters in his code in {$h-} mode.

Jonas

Thanks for pointing out. Nevertheless Rainer said that he has that problem with 2.4.2 (at least according to his first mail).

Regards,
Sven

(I should have read the listed change before clicking "Send")

So using 2.6.0+ Rainer would at least now know that he has a constant string > 255 in mode $H- and that this would have been truncated before.

Regards,
Sven

Felipe Monteiro de Carvalho wrote

On Tue, Nov 15, 2011 at 11:33 AM, Jonas Maebe

> length(pchar) is translated into strlen(pchar) (just like in Delphi). But why is it limited to 255 chars in {$H-} ? (I understood that it is limited like this from the original poster)

Exactly.
Why?

Now I changed all string vars (aprox. 1250) to shortstring and the string[..] vars remain the same as before.

So now I can remove the swith -Sh- from additional compiler arguments/flags. And now it is possible again (like in the compiler versions before) to put more than 255 chars incombination with a pchar.

Indeed - TP/BP 7.0 gives the same (error) result. Unit strings (which might be more appropriate than unit objects included by Bart) doesn't change the result either.

Tomas

Jonas Maebe wrote

Again: length(pchar) is perfectly correct and will be translated into strlen(pchar), just like in Delphi (and probably even like in TP).

Couldn't resist;

Turbo Pascal 6.0:

Program Prog;
uses objects;
var
  pc: PChar;
  Len: Integer;
begin
  Len := Length(pc|);
end.

Error 67: String expression expected. (| indicates the cursor)

Bart

Tomas Hajny wrote

Indeed - TP/BP 7.0 gives the same (error) result. Unit strings (which might be more appropriate than unit objects included by Bart) doesn't change the result either.

Getting really Off-Topic ;-)
PChar is defined in objects unit in TP6, there is no strings unit in that version.

Bart