Some unexpected behavior here. On your side or on mine. Probably mine I cannot get printf to understand that x is a float of only 4-bytes. (isn't it?)

prints


This adds complications to my debugging and education.

I also noticed that when defining a float, it takes up 8 bytes despite sizeof(float) = 4; I think the compiler forces 8 byte alignment. Maybe this explains why I'm having so much trouble reading in a bin?

Since floats have burned me (I can't inspect them using printf), I'm trying var's. Whoa... var also has surprising behavior in memory.


The 00000008 is where int y landed. I conclude that var is 12 bytes in memory. That's really odd.

In any case, R does not let me dump a 12 byte numeric on this machine.

So many hours

Alright, I found this technique for printing the internal representation of floats. http://www.geeksforgeeks.org/how-will-you-show-memory-representation-of-c-variables/ I see that the values in memory are correct. It's just that printf with a float is undefined. It just silently prints wrong values, perhaps by eating extra bytes?. The correct method is to typecast all float inputs to double.

Can I say that this is special kind of evil?

Anyway, I find that with (my understanding of) your file_read technique, the last two bytes of my array do not match my data file. Is it possible you meant to suggest this, instead?

int size = 121*30*sizeof(float);
float* pc_1 = (float*) malloc(size+1);
file_read("myvars.bin",pc_1,size+1);

That is, not only alloc an extra byte, but also read an extra byte?

Ok, 3 problems at the same time

- you want to read (size) bytes from the file, not (size+1). The function adds a 0 byte at the end, therefore your array must be bigger by at least 1 byte, but not the file.

- a float is always 4 bytes, and var/double is always 8 bytes. Look here: http://manual.zorro-trader.com/aarrays.htm

- The %f placeholder in printf expects var/double, not float! Look here: http://manual.zorro-trader.com/printf.htm

If a C function expects a var and you pass a float instead, it's normally automatically converted and you need not bother. Not so with printf: It has no fixed variable types. So you must always pass the correct type that is expected for the placeholder. Otherwise you'll get garbage.

In fact it's 5 problems:

var *xp = &x;
printf("\n%08x %08x %08x %08x", *(xp), *(xp+1), *(xp+2), *(xp+3));

If you add "+1" to a pointer in C, it points to the next element, not to the next byte. You needed char *xp, not var* xp, for reading bytes. And the int has nothing to do with the preceding var, so your printf call can access unallocated memory and randomly crash. You need to define a struct for putting a var and a int together.

Umm, float is automatically promoted to double in variadic arguments (just as char and short are promoted to int). At least, according to the C standard. Since variadic arguments aren't supported in Lite-C directly, but it's still there for support with external languages, I would have assumed that the compiler conforms to type promotion rules?

Yes, the lite-C compiler knows no variadic arguments. Calling external functions with variadic arguments just switches off the parameter type/number check - that's all. Therefore, the correct parameter types must be always passed to variadic argument functions.

But that was exactly my point!

va_arg(foo, float) is undefined behaviour, because float is automatically promoted to double when passed to a variable argument, because the compiler can't deduce the right type and default argument promotion kicks in. Here is the relevant quote from the C standard (emphasis mine):

(ISO C99, latest draft, §6.5.2.2)

Yes, it's a stupid rule that is dragged along because K&R C didn't have support for function prototypes. With all that said, it breaks support for external languages badly. Sure, you may now argue that variadic functions are rarely used, to which I'm going to argue that they are used quite extensively when it comes to scripting languages. Can this at least be mentioned in the manual? Because other languages will expect default type promotion because not expecting is results in undefined behaviour.


Edit:

I would like to confirm that! I have used multidimensional arrays in various circumstances before and I'm the biggest pussy on earth. I also very much like compiler boundary checks and faster insertion/deletions of whole rows when working with dynamically allocated ones.