Netlinx Compiler Bugs
AMXJeff Posts: 450
After seeing that strange bug that the NetLinx compiler did not catch. I thought it a good idea to have a thread that we can all show the strange things that the NetLinx compiler catches and in turn misses. So have at it, maybe this will lead to some fixes.
this made me laugh
as posted by mpullin
Normally when writing code I have a trigger happy compile finger. Whenever I add a function or two or add any significant code I compile to make sure I didn?t screw anything up.
On this particular occasion I was on a cut and paste rampage, adding include files, basically working with code I already trusted. When I finally decided to compile I got the following error.
ERROR: (0): C10580: Internal Error: Major system error occurred during code generation
That error was all I had to go on (no line numbers no nothing) so I started retracing my steps commenting out code that I added until I had the slap my palm into my forehead moment when I realized I had duplicate function names in two different include files.
Anyhow I think the compiler should be smart enough to realize it ran into a duplicate function name and flag the user with the file name and line number instead of generating the major system error with no clue on what to look for.
Here is a fun one...
This line doesn't look correct. You are passing a boolean to get_last? How is that going to work?
I can't get either of those examples to compile. Don't you mean [dvRelay,1] =! [dvRelay,1]? I don't know what [dvRelay,1] != [dvRelay,1] could mean in that context even with a semi-colon.
[dvRelay,1] =! [dvRelay,1] should really be written as [dvRelay,1] = ![dvRelay,1] so that it is clear what is being negated.
It can't, that was the problem. The point is, the compiler didn't catch it.
if you see the difference between axcent compiler errors and netlinx compiler errors i'm very gratefull it has 'advanced'. Still, those 'silly' compiler errors should be fixed
The compiler accepted the line below, which I copied from another programmer's code, thinking it elegant:
IF (7 < nTIMEHOUR < 19)
The compiler accepts this just fine, but the parenthetical expression appears to evaluate at run time to true, regardless of value of the integer nTIMEHOUR.
I put back the code I had in the first place - IF ((nTIMEHOUR > 7) && (nTIMEHOUR < 19)) and all worked well again. I asked the other fellow about this and he mumbled something vague ....
BTW, I did also find another problem with this same routine - I originally named the variable nHOUR, and the routine did not work (with the correct version of the code). In debugging I found that nHOUR appeared to always be zero even right after the statement nHOUR = TIME_TO_HOUR (TIME); it appears that nHOUR is used somewhere in the system routines and so created a conflict, a problem which the complier did not have the grace to inform me. Changing the variable name solved the problem.
I have also gotten the "general system error" message, several times. I forget what I did but I recall it was obvious when I did realize it; perhaps it was duplicate functiion or subroutine names.
I wouldn't expect this to work as you think. I am guessing the compiler evaluates 7 < nTIMEHOUR first, and the result would be either 0 or 1 depending on the value of nTIMEHOUR, and then evaluates 0 or 1 < 19 which of course is always true. While you cannot expect the compiler to stop poor programming practise I do expect it to do what the docs say it does, which is often is not the case.
[Relay,1] = ![Relay,1]
Or to be even more anal-retentive (picture me waving):
[Relay,1] = (![Relay,1])
I've gotten parenthetically anal retentive and do stuff like that by default, having been bitten by more complex evaluations that get past the compiler, but don't give the result I want. I figure if I'm going to have to be that specific in larger evaluations, I'll be that specific in the smaller ones just to keep the habit.
And while we're talking about old school-ness, get rid of all that "dvThis" and "dvThat" crap. Talk about extra typing that doesn't help anything. If I can't tell from looking at the identifier name that it's representing a variable or a device, I think I've got bigger issues.
Same goes for variables.
- Chip (Crotchety old programmer)
I had this one too, it ended up being two functions with same name...both in my main program.