Here are the steps I follow to reproduce the issue:
In a .comp file declare a pointer variable with a start value:
variable double *my_ptr = NULL;
This is what I expected to happen:
Halcompile should generate this code in the export function:
inst->my_ptr = NULL;
This is what happened instead:
It generates this code:
inst->*my_ptr = NULL;
This of course will not compile.
Information about my hardware and software:
Latest Git master. I have not tried previous versions
评论 (6)
#2 – andypugh 于 2019-08-14
This appears to have escaped notice previously because nobody has tried to initialise a pointer in the declaration line before.
(pointers in comps were added so that the mesa_7i65.comp could work)
A workaround would be to initialise in the EXTRA_SETUP, or indeed to leave it uninitialised.
Arguably halcompile should automatically initialise to NULL whether the programmer does so or not.
#3 – LesNewell-SheetCam 于 2019-08-14
Yeah, I guessed this was a bit of an edge case. As you suggested I initialized it in EXTRA_SETUP instead.
#4 – jepler 于 2023-01-19
Note that because the whole instance’s data is memset to 0, this is equivalent to initializing any pointer variables to NULL, any numbers to 0, and so forth.
#5 – jepler 于 2023-01-19
(this, the equivalence between all-bits-zero initialization and NULL pointers or floating-point zero values is not strictly true under the C99 standard, but is true of any system where LinuxCNC runs)
#6 – andypugh 于 2023-05-07
I think that I have decided to leave this. The issue is that there is no way to tell if the programmer intended
*(inst->pointer) = Value (which makes no sense with a dangling pointer) or inst->pointer = Value which only makes sense with NULL and in that case is unnecessary.
Leaving things as they are has the effect, at least, of making the programmer change the code to do what they intended.
#1 – LesNewell-SheetCam 于 2019-08-14
A correction to the information above: This error showed up on 2.7.14. I did not test master.