Thanks, fix is submitted to
https://github.com/freebasic/fbc/pull/112
The changes to fbc in August removed some special cases where const was ignored or improperly handled. Almost all of the internal run time library declarations were modified to include a const qualifier on parameters. I missed updating the declarations for lbound & ubound causing this bug. An easy fix, 2 lines, and I wrote a regression test.
While investigating the L|UBOUND( const array() ) bug reported in this topic, I found this other bug, seen also in fbc 1.05.
Code: Select all
dim shared array(1 to ...) as integer = { 1, 2 }
dim shared const_array(1 to ...) as const integer = { 1, 2 }
sub s( array() as integer )
end sub
sub const_s( array() as const integer )
end sub
s( array() )
const_s( array() )
const_s( const_array() )
fbc 1.05 wrote:
xx.c:43:8: error: redefinition of 'struct $8FBARRAY1IiE'
struct $8FBARRAY1IiE {
^~~~~~~~~~~~~
xx.c:32:8: note: originally defined here
struct $8FBARRAY1IiE {
^~~~~~~~~~~~~
So, I have a proposed fix for that as well.
There is still
https://sourceforge.net/p/fbc/bugs/823/ to fix, which involves overloaded procedures and const/non-const arrays. It involves a different part of the compiler from these fixes.
Const arrays, especially those passed BYDESC, need a lot more testing.
In general, the parser is supposed to figure out if it is OK to call an internal run time library function. With the changes in 1.06 in August, there may be some cases where the fbc parser misses it, but will catch the error instead when trying to call the run time library function (due the const checking). However, it results in a somewhat cryptic error message, and should be reported as a bug so we can update the parser to report a meaningful error message.