Hi all! Lately I’ve been encountering really random values in the integer variables from my custom data struct that holds all the parameter values (contains bools, ints, floats and doubles, and other structs that contain more of those data).
The problem is the int values would randomly take the value 1065353216, which I’ve found that is the unsigned int representation for the float 1.0. And by randomly I mean for example in oscillator[0] the ints take a correct value, but oscillator[1] contains some 1065353216 int value and some correct ones). On startup, before even processing anything (and after correctly initializing the whole data struct with hard coded values).
When I use floats instead of ints in the struct the problem just goes away. Does anyone encountered the same problem?
This is an obscure sounding issue, which will certainly require more information to diagnose. ie. we need to see some minimal amount of code…
(Edit: removed distracting code as it wasn’t called)
The parameter struct is huge but it’s just like:
struct Parameter
{
struct Oscillator
{
int waveform {0}; // 0 = sine, 1 = saw, 2 = square...
double angle {0.0};
float gain {1.0f};
} oscillator[2];
struct Envelope
{
float attack {0};
float decay {1.0f};
float sustain {1.0f};
float release {0};
} envelope[2];
} parameter_struct;
And so on. This for accessing parameters (didn’t wanna go for a value tree) worked fine for weeks, it’s not anything fancy, but 2 days ago just started giving problems. I first suspected about some memory corruption or mismanagementor some uninitialized value, but then I found that exact 1065353216 value had some “background” behind
Not that I know what happens, but I’d try changing the order in Oscillator to waveform / gain / angle (int / float / double), to avoid padding.
oh, and your implementation may not be cross-platform, as it writes out raw data, not taking into account endianess, or, if structure padding is different on the platforms compiler…
You don’t say what values you’re talking about. Then only integer I see in that code snippet is the waveform member. What values are you referring to? Where is the code that deals with those values (defines them, and reads/writes them)?
Yes the save/load is just for testing purposes for now. Not intended for a “final product” usage
Which values don’t matter as much as they present themselves randomly with altered value. I.e the oscillator[0] int will be okay (with its inited value at 0) and the oscillator[1] int will present itself as 1065353216 even after being inited to 0. Other times it will be the other way around.
No more processing is made on those values, they are just used to read so no more startup functions modify the parameter_struct.
I think the safest thing I can do is to roll back to the lastest working version and just reimplement everything again, as it seems I may spend more time trying to figure out this tricky behaviour than just recoding the last 2 days again.
That’s very confusing. When you say “oscillator[0]”, you are apparently referring to a struct, not a value. You have defined oscillator as a struct of type Oscillator, with three member variables. So it doesn’t actually have a single value. With no code showing what you’re talking about, we can’t even guess what the problem might be. Just saying, if you do want help, we need more specific information.
I said oscillator[0] int (refering to the int variable inside the oscillator[0] struct) but yes I recon that I made it a bit confussing.
I realized some init values were hardcoded with floats instead of ints, so that’s what may be causing the problems. I expected them to actually cast to int, but I don’t understand why sometimes they properly cast and get a right value, and other times they are treated like unsigned integer representation of that float (hence that big value), even less why those problems started out of nowhere after many weeks of using the same code.
Initializing an int with a float literal will cause a compilation error for the narrowing conversion, so this is still confusing. Nothing in the type system itself will cause a bit cast out of nowhere. Something is going wrong with the serialization that is causing a stored float to be written on an integer field, that’s why I thought about padding, but it’s very hard to say anything else with these snippets. For this kind of thing you have to be sure that all your targets will agree on sizes, alignments and endianness, but if this is happening on a single target, it’s weird indeed.
If you were to produce a small complete code snippet which shows the issue, I would be willing to take a look at it in a debugger… you might even discover the issue by trying to create the sample code. 
1 Like
The only int member of that struct is waveform. So, are you saying you’re seeing a problem with the value of oscillator[0].waveform?
He says he isn’t calling the code that loads that data, which is why I ignored it. 
Found it! thanks for your help and sorry for the mess of explanations, I was kinda stressed mangling code up and down while responding here.
What was happening is: I was actually hardcoding the values in the struct declaration with init values like this:
struct Vehicle
{
int num_wheels {0}; // set to 0 as we don't know which vehicle we instantiate
} vehicle;
But at the same time in the Main constructor (as a temporary init test 
), I was setting up the values to some I wanted to test. I.e:
vehicle.num_wheels = 4.0f;
But I assigned some of integer variables inside the struct using floats like I did here, instead of assigning an int or making an int() cast. So this indeed gives the 1065353216 when doing so. If I had done it in the struct itself the compiler would threw me a narrowing conversion error, but here it didn’t say anything.
The mysterious stuff is why this didn’t show up until now as I had that “temporary test” set many time ago or why sometimes the variables in the struct came as correct values, and other times came with 1065353216.
Edit 2: the modified values were because I was writting out of index in the heap, so instead of throwing the error it just wrote in the next members of the structs
