I found an error.
Source:

const
CharsDes1:array[0..383]of char=
'0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'+ '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'+ '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'+ '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'+ '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'+

  '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF';

var rr,rt:longint;
begin
 for rr:=0 to 383 do begin
  write(CharsDes1[rr]);
 end;
end.

The program just writes the first 255 characters and the other characters instead of write zero codes.

I think it's a bug because the 'string' isn't equal 'array[0..x]of char'.

The problem is that, when you Assign something to a var-constant (initialized variable array),
the expression (your long string) will get processed first, before passing along to the const/var.
Thus, the shortstring Concatenation operation truncated your string before it is passed to the const.

It is perfectly fine with your data structure. The problem is the way that it is assigned.
(In other words, you cannot initialize that array directly)

This problem dates back to a similar TP7 problem, where const BigNum=1000000000000000;
will cause an error, because TP7 assumes any number without decimal to be an integer.
(This does not happen on FPC, because it is clever enough to do implicit typecast on constants as well)

Any solutions (tricks, hacks, ...) ?

[cut]

This is correct.

It is perfectly fine with your data structure. The problem is the way that it is assigned. (In other words, you cannot initialize that array directly)

Yes you can, but it's a lot more typing work:

const
CharsDes1:array[0..383]of char=
('0','1','2','3','4',...)

Jonas

[...]

This works with PChar type:

const
CharsDes1:PChar=
'0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'+

Andras

>Thus, the shortstring Concatenation operation truncated your string before >it is passed to the const. This is correct.

No, it isn't. The strings are concatened as ansistrings but when writing the constant, the string is cut off to 255 chars, see ptconst.pas
around line 540:

                   p:=comp_expr(true);
                   do_firstpass(p);
                   if p^.treetype=stringconstn then
                    begin
                      if p^.length>255 then
                       len:=255
                             ^--- should we fix this?
                      else
                       len:=p^.length;
                      s[0]:=chr(len);
                      move(p^.value_str^,s[1],len);
                    end

It depends on the type of the const:
- For shortstring it should be cut.
- For pchar not (obvious).
- for array of char not.
- for ansistring don't cut either.
Is it possible to determine the type here ?

Michael.

Make that pchars :)

Jonas

> No, it isn't. The strings are concatened as ansistrings but > when writing the constant, the string is cut off to 255 chars, see > ptconst.pas > around line 540:

...

It is know that it is an array of char .

A stupid and dirty solution: use more arrays, as many as you need, declared one after the other, and then use the first array with the index going outside boundaries. I did'nt test this, but should work - only pay attention at the alignment (word or longword). I've seen the Pchar solution, and seems better.

_________________________________________________________ Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Check Data2inc in the utils directory. IIRC it could change textfiles to array of char output like above.

Marco van de Voort ( or )

Fixed. Only for tp mode the length is now limited to 255. Also for pchars the length is limited to 255 in tp mode.

Peter