rtl_power (original)shows trash values or lets say it display a string instead of a number "nan".
It works on a real computer.
I have a modified rtl_power version, moving around some global variables into functions solves 1 Output.
But i cant do this for any variables.

So i think RPI/Raspbian gcc is buggy, cause it output different things on different computer and strings instead of numbers.
Any way to solve this?

WIth out some sample code that demonstrates the problem it's hard to see how anyone is going to be able to help you.

And making comments like "on a real computer" won't encourage us to help you either

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Thats the rtl_power.c from the "librtlsdr" package, its free available but i dont think that iam allowed to Post the whole sourcecode.
My modified code is almost the same, but it first collect all dbm and then print it.
The values goes from -41 to -18
I doesnt know that a raspberry is holy for some people.
I am of course annoyed that basics like wifi or compiling a program dont work but with "real computer" i mean a Desktop x86 Computer with Linux.

Thats the rtl_power.c from the "librtlsdr" package, its free available but i dont think that iam allowed to Post the whole sourcecode.
My modified code is almost the same, but it first collect all dbm and then print it.
The values goes from -41 to -18
I doesnt know that a raspberry is holy for some people.
I am of course annoyed that basics like wifi or compiling a program dont work but with "real computer" i mean a Desktop x86 Computer with Linux.

In C local variables are allocated from the stack. If local variables are not initialised, they will contain what ever data was left over from previous use of the stack. This is by design for efficiency. There are thousands of bit patterns which mean not a number in the IEEE floating point standard used by all current computing hardware. Specifically, for double precision we have

A signalling NaN is represented by any bit pattern
between 7FF0000000000001 and 7FF7FFFFFFFFFFFF or
between FFF0000000000001 and FFF7FFFFFFFFFFFF
A quiet NaN is represented by any bit pattern
between 7FF8000000000000 and 7FFFFFFFFFFFFFFF or
between FFF8000000000000 and FFFFFFFFFFFFFFFF

Differences in runtime environments imply that x86 and ARM architectures leave different bit patterns on the stack that can be picked up by uninitialised variables. The solution is don't print the values of uninitialised variables and expect sensible output.

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

In C local variables are allocated from the stack. If local variables are not initialised, they will contain what ever data was left over from previous use of the stack.
..
Differences in runtime environments imply that x86 and ARM architectures leave different bit patterns on the stack that can be picked up by uninitialised variables. The solution is don't print the values of uninitialised variables and expect sensible output.

If that happend ggc would print a warning like "x is uninitalised in function y".

If x is negative (including negative infinity), then a domain error
occurs, and a NaN (not a number) is returned.

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

You did say "I have a modified rtl_power version, moving around some global variables into functions" so maybe it is your fault ?
But if you still think it's a bug then you need to raise a bug on the librtlsdr github site, they are the people that you should be talking to.
PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

You did say "I have a modified rtl_power version, moving around some global variables into functions" so maybe it is your fault ?
But if you still think it's a bug then you need to raise a bug on the librtlsdr github site, they are the people that you should be talking to.

I used the original rtl_power version for testing. I have too have a modified version.

Think i found it already arm/rpi seems have 4 bytes for datatype "long" and x86 have 8bytes.

You did say "I have a modified rtl_power version, moving around some global variables into functions" so maybe it is your fault ?
But if you still think it's a bug then you need to raise a bug on the librtlsdr github site, they are the people that you should be talking to.

I used the original rtl_power version for testing. I have too have a modified version.

Think i found it already arm/rpi seems have 4 bytes for datatype "long" and x86 have 8bytes.

So it's badly written (non-portable) code if it makes assumptions about data type sizes. 32/64 bit issues are not that hard to avoid.
PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson