in RTEMS initialization routine, I see this code below.
void boot_card(const char *cmdline)
{
rtems_interrupt_level bsp_isr_level;
/*
* Special case for PowerPC: The interrupt disable mask is stored in SPRG0.
* It must be valid before we can use rtems_interrupt_disable().
*/
#ifdef PPC_INTERRUPT_DISABLE_MASK_DEFAULT
ppc_interrupt_set_disable_mask( PPC_INTERRUPT_DISABLE_MASK_DEFAULT );
#endif /* PPC_INTERRUPT_DISABLE_MASK_DEFAULT */
/*
* Make sure interrupts are disabled.
*/
(void) bsp_isr_level; // <---
rtems_interrupt_disable( bsp_isr_level );
-- continues--
In the code above, at the beginning, bsp_isr_level is declared as of type rtems_interrupt_level (which is ultimately type defined as unsigned int).
But, what is the line (void) bsp_isr_level;
doing? (marked with //<-- above). It's not a variable passed in as the function argument as in here.
EDIT : I found in my case the variable is being assigned by the rtems_interrupt_disable function (actually it is a macro #defined) so it's not 'not being used'. But though assigned, the assigned values seems to be not used. I don't know if this syntax is used also for cases like this(value assigned but not used). By the way, I found in the RTEMS source tree there is a function(real function, not #defined) rtems_interrupt_disable having void argument like below. (in cpukit/rtems/src/intrbody.c). (The #defined version is in cpukit/rtems/include/rtems/rtems/intr.h)
rtems_interrupt_level rtems_interrupt_disable( void )
{
rtems_interrupt_level previous_level;
_ISR_Disable( previous_level );
return previous_level;
}
So Maybe this syntax might have been used just in case this second definition(the value is passed as void to a function). I guess because this second definition exist, that can be used in some build cases.
It's not doing anything.
Casting a variable name to (void)
is a common way to say "throw this away", while still referencing the named variable.
It's typically done inside functions, to "use" arguments that would otherwise trigger a warning of an unused argument or variable.
In this case, it looks unnecessary and might be residue from refactoring.
I dug around a bit in their public Git (I don't know RTEMS either) but it's not possible to run a blame
without doing a local clone, it seems. From looking at the head version of the file it seems clear there are no preprocessor tricks surrounding the code in question, it appears as quoted.