Possible bugs with new Reformat Code at compile time option.

Previous topic - Next topic

Hatonastick

Bug #1 and a request:
One little problem with the new Reformat Code option (actually it was a problem with the editor before, but I used to edit it out by hand whenever the editor changed it by mistake) is this: C/C++ functions/commands in INLINE sections that share names with GLB functions get renamed in upper case eg. for (in C) becomes FOR, which of course generates an error. Is it possible for the editor (Ill understand if it isnt) to ignore and not alter anything marked with INLINE/ENDINLINE? Of course if an ENDINLINE is temporarily missing, it might reformat the code anyways no matter what...   

Bug #2 (closely related with Bug #1):
Another problem with the Reformat Code option is that I can't turn it off. I turned it on to try it out, but now (even though the option is no longer ticked on the options screen) it still reformats all the code every time I go to compile -- so my Mersenne Twister library will no longer compile under this update. 

Edit: Ok that's odd. Even if I change the C back to lower case, save, exit, then reload the project and it's back to uppercase -- even though the Reformat Code option is supposedly turned off.

amarliani

Yep, ran into the same problem. Since that new update my mersenne-based programs don't compile anymore.

BTW, great work, Hatonastick! Thanks for implementing that algorithm, I was looking around for some time for a better random numer generator.

Hatonastick

Thanks. :)  Yeah currently anything with INLINE is unlikely to compile as C compilers don't like it when C commands suddenly change to uppercase at compile time. :)

Also I'm currently (possibly -- it may just be me!) getting odd behavior with GLOBAL variables.  The compiler gets upset if I place variables outside functions, and for some reason all my variables inside functions (the ones that aren't labeled LOCAL at least) are now GLOBAL.  I've just tested LOCAL variables and they are definitely local.

File 1

Code (glbasic) Select
// It doesn't matter if we have these two GLOBALS uncommented or not, the variables in ZB_Init() seem to be GLOBAL.
// However turning Explicit Declarations on gives us an error and tells us to put these inside a function or subroutine.
// Our keywords array used in parsing.
GLOBAL ZB_Keywords$[]

// Total number of keywords.
GLOBAL ZB_KeywordsTotal%

// Both of the following are GLOBAL with or without the above declarations.
// Also if either of the following are moved outside of a FUNCTION or subroutine, the compiler generates a fatal error message.
FUNCTION ZB_Init:
DIMDATA ZB_Keywords$[], "+", "-", "/", "*", "(", ")", "<", ">", "<=", ">=", _
"==", "<>", "$", "#", "@", ":", "\"", "PI", "POW", "SQRT", "RND", "MOD", _
"ABS", "INSTR", "LEFT", "LEN", "MID", "RIGHT", "SPACE", "STR", "STRING", _
"SWAP", "VAL", "LET", "DATA", "READ", "RESTORE", "CALL", "PRINT", "END", _
"FOR", "TO", "STEP", "NEXT", "IF", "ELSEIF", "ELSE", "ENDIF", "WHILE", _
"WEND", "GOSUB", "RETURN", "REM"

ZB_KeywordsTotal% = BOUNDS(ZB_Keywords$[], 0)
RETURN
ENDFUNCTION


File 2
The following gives these warnings under Debug mode no matter whether the above GLOBALs are declared or not:
warning : implicitly created GLOBAL  : ZB_KeywordsTotal
warning : implicitly created GLOBAL  : ZB_Keywords$
Code (glbasic) Select
ZB_Init()
LOCAL i
LOCAL j = 0
LOCAL k = 0
FOR i = i TO ZB_KeywordsTotal% -1
PRINT ZB_Keywords$[i], j , k
j = j + 60
IF j > 580
j = 0
k = k + 20
ENDIF
NEXT
SHOWSCREEN
MOUSEWAIT
END


Something odd is going on, I've made a really daft mistake, or I've misunderstood how this all works and it's working as intended.

matty47

I tried your code and if I type it as presented, that is with the function declaration before the main code I get
"DeclarationTest.gbas"(17) error : command not inside function or sub
I have noticed this before. It appears that you must place all function definitions after the main loop? - well that is my observation.
If I put the function definition after the main loop your code compiles and runs with no errors (in debug mode at least).
Hope this was of some help

Kitty Hello



neseir

Looks like the uppercase function also makes some problems related to the Newton wrapper:

Code (glbasic) Select

FUNCTION NewtonBodySetUserData: body_index, DATA
INLINE
xNewtonBodySetUserData(gNewtonBodyPointers((int)body_index).ptr, (void*)(int)data );
ENDINLINE
ENDFUNCTION


Causes the program to fail on the declaration of the data parameter. Changing the data to e.g. udata and it compiles ok.

Kitty Hello