Assignement binary value to a variable dosn't work

[nico23]

As title suggest.

If I do

int my_var;
my_var = 0b01;

 my_var stays 0

Instead with

int my_var;
my_var = 0x01;

Everything works

STM32CubeIDE

Version: 1.14.1

Build: 20064_20240111_1413 (UTC)

[Andrew Neil]

Do you get any warnings/errors ?

Binary literals aren't part of the C standard - only available by extension - so are you sure it's valid for the language spec you're using?

CORRECTION

Binary literals were introduced in C23:

https://queue.acm.org/detail.cfm?id=3588242#:~:text=C23%20understands%20binary%20literals%20and,binary%20(%2201010101%22).

So they are very new!

[STTwo-32]

Hello @nico23 

I've personally tested using the STM32WB55-NUCLEO and the STM32CubeIDE V1.14.1 and this simple code:

  /* USER CODE BEGIN 1 */
	int my_var;
	__NOP();
	my_var = 0b01;
  /* USER CODE END 1 */

And that works fine (even without the __NOP() ) and set the my_var to 1 as you can see: 

Could you give more details about your issue.

Best Regards.

STTwo-32

[SofLit]

And if you add volatile to your declaration :

volatile int my_var;?

[Tesla DeLorean]

That might not help prevent it from being optimized.

Memory inspection only works if the value is in memory, not in registers.

Get printf() / STDIO plumbing working, and printf() the value, or sprintf() via HAL_UART_Transmit()

[Tesla DeLorean]

Still, likely to be exceedingly non-portable..

[SofLit]

---

Memory inspection only works if the value is in memory, not in registers.

---

Indeed, but in the current case the variable and its affectation is in the memory. 

[Andrew Neil]

---

@SofLit wrote:

Indeed, but in the current case the variable and its affectation is in the memory. 

---

Well, in your test they were - we can't tell what happened in the OP's case ...

@nico23 - you need to provide a minimum but complete example which illustrates the issue.

[Tesla DeLorean]

Contextually its not presented well enough.

Could be an auto/local variable, which might mean it's held in a register or on the stack.

If it's not throwing a syntax error on compilation I'd assume one hurdle has been jumped. Looking at a disassemble or listing file might give an idea about what is / is not happing.

Not clear how it's being viewed, or how the determination is made it has the wrong value in reality.

[TDK]

There is no chance the compiler is not handling this correctly. Likely to be you misinterpreting the data. Not enough information presented to reproduce or even verify the claim.