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

Question

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.

Prevot

Answer 1

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.

Urease

"In this case, it looks unnecessary" - unless rtems_interrupt_disable can get #defined away to nothing? (Although it that case maybe it ought to be #defined to the (void) pattern.) But I'm guessing, I don't know RTEMS. – Wattle

could be that in test cases functions are stubbed away. rtems_interrupt_disable might not be there in host executed test cases. (assuming this is an embedded RT) – Chemar

@Urease thanks. but it's not exactly the case you mentioned (to avoid warning from not using a variable passed in as function argument). Through experiment, I found in my case the variable is being assigned at rtems_interrupt_disable macro at next line. But the assigned value is not being used. see my EDIT in the original question. – Prevot