2

I'm working with GCC compiled C libraries in an embedded environment, and as part of my development process I am testing the compiled libs in python. I'm compiling a .a lib for embedded use and a .dll lib for python. The idea of this part of development is to mirror the embedded C environment in python, as far as possible.

If a variable is not explicitly initialized in C code, it's value is not zero, but will be whatever is represented by the allocated RAM for that variable. This means that the behavior can be non-deterministic, which is why it's a good idea to always give variables an initial value.

In my "c-wrapped" python code implementation, I've found that the behavior differs from an embedded environment, and that un-initialized variables always default to zero. It would appear that when the lib is loaded in python, all of the RAM allocated to the lib is set to zero before any code is executed.

So, the questions:

  • Is my understanding sound regarding the loading of a C lib in python, or am I missing something?
  • What would be the best way to write random data to the allocated RAM, for the python implementation, after the lib is loaded?
ComplexCarbon
  • 21
  • 1
  • https://stackoverflow.com/questions/1597405/what-happens-to-a-declared-uninitialized-variable-in-c-does-it-have-a-value. ***U**ndefined **B**ehavior*. So, don't write poor code and then search for lame workarounds (*gainarii*) like the 2nd bullet to match it, but write good code from the get go and avoid any unnecessary complications. – CristiFati Sep 04 '20 at 08:32
  • Not my C code. Verification en-devour. But thanks. – ComplexCarbon Sep 04 '20 at 10:43
  • Sure. *Undefined Behavior* is tricky. In some conditions it might work perfectly every time. In others it might crash every time. In most of them a crash occurs "randomly", or other strange behaviors might be encountered. The bottom line is not to rely on the fact that if in some circumstances it worked well, it will also work well the next time, or in other circumstances. It should be the other way around: considering the fact that it works as a bug (and treating it accordingly) :) – CristiFati Sep 04 '20 at 10:51
  • I agree wholeheartedly. I would still like to be able to randomize the RAM python allocates to the c-lib, as part of the verification testing. Any help regarding this would be appreciated. – ComplexCarbon Sep 04 '20 at 13:00
  • I guess this is behavior comes from OS and not from Python. On modern OS, when process gets memory from the OS it is zeroed (otherwise this process could the memory from others processes which is a problem). As you don't really controls which memory page you will get from the OS, you cannot ensure that it is not zeroed. – ead Sep 04 '20 at 13:55
  • For allocations on the heap, you could override malloc , not sure `ldopen` uses malloc for everything though... – ead Sep 04 '20 at 13:57
  • BTW could you give an example of the C code, which would lead to uninitialized data on your embedded environment but not one Windows/Linux. Global variables are always zero initialized, local variables are probably on the stack or in a register - these values you cannot influence directly. – ead Sep 04 '20 at 14:26
  • Some embedded tool chains provide options to disable initialization of global variables (which is not standard conform), maybe this is the difference you see? – ead Sep 04 '20 at 14:35

0 Answers0