ver 8.3 array of char

[janni]

Compiler miscounts the elements of char array and not only issues warnings but also reserves more space in ROM than necessary. For example, this code

Code: Select all

program testv83;

var bb: byte;
    ch: char;
    myPtr,myPtr1: ^byte;
const aa1: array [1..2] of char = ('0','1');
      aa2: array [2] of char = ('0','1');
BEGIN
     ch:=aa1[bb];
     ch:=aa2[bb];
     myPtr1:=myPtr;
END.

produces warnings about aa1 & aa2 having too few elements. For PIC18s there is additional Flash reserved for 'padding the arrays with zeroes'. For PIC16s, apart from compiler warnings, the 'constant array' bug reported by MAN in mB forum will not let linker to finish the job.

The pointer variables, myPtr & myPtr1, were placed in code to point to another quirk - compiler issues nonsensical warning, 'implicit typecast of integral value to pointer', for the assignment myPtr1:=myPtr.

Hopefully somebody still works on v 8.3 and noticed my other post about the Hi(real) bug.

[zristic]

Hopefully somebody still works on v 8.3 and noticed my other post about the Hi(real) bug.

You know very well that we do.
Thanks for the report.

[janni]

You know very well that we do.

I know very well that you have more than enough work at the moment .

[zristic]

I know very well that you have more than enough work at the moment.

You cannot know that, you can only believe in it. It is different.

[janni]

You cannot know that, you can only believe in it. It is different.

As long as we're having fun playing with words - I can only belive that you're working on v8.3 , but I know that you have a lot of work seeing the number of promises and the cautious time estimates (or lack of them) in the aforementioned promises made in various compiler forums.

Whether you actually do the work - well, I have a lot of faith in mE's development team, whatever my unfortunate, cutting style of writing suggests.

[joseLB]

Hi Zoran
What about, taking the opportunity and tell us just a bit how things are going? Just few lines?

[Dany]

Hi I did some tests on v8.3 Bèta too, and I think the rom/ram space behaviour of char arrays and strings is the same as in v 8.1: one extra byte/char is reserved for the trailing zero:

Code: Select all

var Strng: string[10];
    Test: array[5]of Char;
    Test2: array[5] of byte;
    Test3: array[1..2] of char;
    Test4: array[1..2] of byte;
    I: byte;
    
const ConstStr : string[10] = 'abc';
      ConstArr : array[5] of byte = (1,2,3,4,5);
      aa1: array [1..2] of char = ('0','1');
      aa2: array [2] of char = ('0','1');
      
begin
  I := SizeOf(Strng);    // returns 11  (string[10])
  I := SizeOf(Test);     // returns 6   (array[5]of Char)
  I := SizeOf(Test2);    // returns 5   (array[5] of byte)
  I := SizeOf(Test3);    // returns 3   (array[1..2] of char)
  I := SizeOf(Test4);    // returns 2   (array[1..2] of byte)
  I := SizeOf(ConstStr); // returns 11  (constant string[10])
  I := SizeOf(ConstArr); // returns 5   (constant array[5] of byte)
  I := SizeOf(aa1);      // returns 3   (constant array [1..2] of char)
  I := SizeOf(aa2);      // returns 3   (constant array [2] of char)
end.

I do not get any errors about too less space for "aa1" and "aa2".

[janni]

Danny, there is no need for trailing zero in char arrays (they're not strings). SizeOf(aa1) should produce 2, not 3. You have observed no error because all that happens is a warning and waste of ROM space for PIC18s.

Note also that there will be no warning for the obviously wrong declaration:

Code: Select all

aa1: array [1..2] of char = ('0','1','2'); 

Compiler simply miscounts the size of char array.

[Dany]

Compiler simply miscounts the size of char array.

No it does'nt, please have look at the listfile:

Code: Select all

//** Variables locations **
//ADDRESS		VARIABLE
//----------------------------------------------
$0000		INDF
$0002		PCL
$0003		STATUS
$0004		FSR
$000A		PCLATH
$0020		_i
$0021		_test
$0027		_test2
$002C		_test3
$002F		_test4

Clearly can be seen that e.g. char array "test" takes 6 bytes ($0021..$0026)

[Dany]

Hi, I said before:

I do not get any errors about too less space for "aa1" and "aa2".

Still true, but I do get 2 warnings:

Incomplete definition of array "aa1", automatically padded with zeros
Incomplete definition of array "aa2", automatically padded with zeros

This seems sensible, since the compiler reserves 3 characters and only 2 are defined in the declaration of the constants.
The compiler apparently always does that when too little values are given when declaring constant arrays.

[janni]

This seems sensible, since the compiler reserves 3 characters and only 2 are defined in the declaration of the constants.

And that's where the compiler 'miscalculates'. Declaration for two-element array produces three-element one. Once again, there is no need for trailing zero in char arrays Formally, they do not differ from byte arrays.

[Dany]

This seems sensible, since the compiler reserves 3 characters and only 2 are defined in the declaration of the constants.

And that's where the compiler 'miscalculates'. Declaration for two-element array produces three-element one. Once again, there is no need for trailing zero in char arrays Formally, they do not differ from byte arrays.

Thanks Janni. Obviously mE chose an "array of char" to be like a "string" in terms of bytes reserved and the trailing zero. It is not simply a "miscalculation" I think, but a decision that has been made deliberately.
Of course you are right: normally an "array of char" should not differ from an "array of byte".

Anyway, as far as I can see the behaviour is not different from the v8.1 version regarding arrays of char.

[janni]

Obviously mE chose an "array of char" to be like a "string" in terms of bytes reserved and the trailing zero. It is not simply a "miscalculation" I think, but a decision that has been made deliberately.

No Dany, fortunately it's not intentional and hopefully will be corrected in v8.3. But you're right that it propagated from earlier versions.

[Dany]

Obviously mE chose an "array of char" to be like a "string" in terms of bytes reserved and the trailing zero. It is not simply a "miscalculation" I think, but a decision that has been made deliberately.

No Dany, fortunately it's not intentional and hopefully will be corrected in v8.3. But you're right that it propagated from earlier versions.

Hi Janni, the problem is indeed solved in version 8.3 Bèta.
Extract from the listfile (with the same pascal variable declarations as before):

Code: Select all

//** Variables locations **
//ADDRESS		VARIABLE
//----------------------------------------------
$0000		INDF
$0002		PCL
$0003		STATUS
$0004		FSR
$000A		PCLATH
$0020		_test
$0026		_test2
$002B		_wrd

[janni]

Hi Janni, the problem is indeed solved in version 8.3 Bèta.

Nope . Array of char gets one byte more space in memory than array of byte of the same declared size.