crtems

statement with just a variable name casted (void) in C


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.


Solution

  • 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.