The "bug" that I fixed (in my last post, which still requires testing) was in my code in task main(). (I fixed it.)
afanofosc wrote:
// Report NXC Bug. Can't use "MM_ID ptr = myvar;"
Oh, sorry, I should have deleted that line; my code comments [if any] are a bit misleading at the moment. That line was from before when I was getting random compiler errors on that line; it was actually another bug in the compiler [below].
What I need is a zip containing exactly the files that cause the error - not modified so that the error no longer happens. And preferably simplified to as little content as possible to still have the error occur. And the F12 error listing. So far I have not been able to understand your description of the problem. Are you saying that if I #include a file that #includes 4 or 5 other files - regardless of the content - it will cause a compiler error? Or is it only if one of the include files ends with a block comment?
The "MM-Demo.nbc" is the F12 Code Listing.
(BTW, how do you produce "Code Listing" via command line? -sm- -ER=5 -EF -v=128 -Z2 -L="..." produces a thousand #line xxx "...")
/*
*/
// <ATTENTION> <UNTESTED>
byte MM_get_BYTE(MM_ID /* & is not necessary; pointers! */ id)
{
// <ATTENTION> Possible bug. Do you think using returns like this is *safe*?
return(MM_mem[id.idx]);
}
/*
*/
// <ATTENTION> <UNTESTED>
MM_ID MM_set_BYTE(MM_ID /* & is not necessary; pointers! */ id, byte val)
{
MM_mem[id.idx] = val;
return(id); // return id for no reason
}
The error version has this in "MM-Demo.nxc" instead:
The tokenizer used by the Preprocessor is not returning a token for #endif when there are no more bytes in the file following the "f" Even if you had a space after #endif it would work but not (currently) with the file ending with "f".
Didn't you report some kind of problem also when a file ended with a block comment? Probably the same kind of problem (i.e., no bytes in the file following the "/" at the end of the block comment). Use an editor that adds 0D 0A to the end of your files (like BricxCC does) and you won't have this problem.
afanofosc wrote:Didn't you report some kind of problem also when a file ended with a block comment? Probably the same kind of problem (i.e., no bytes in the file following the "/" at the end of the block comment). Use an editor that adds 0D 0A to the end of your files (like BricxCC does) and you won't have this problem.
Yeah, it works now. The block comment problem was the same; the file ended with "/" with no CRLF or space.)
Commit to LEGO Mindstorms Robotics Stack Exchange: bit.ly/MindstormsSE
Commit to LEGO Stack Exchange: bit.ly/Area51LEGOcommit
