Thread: file size with binary write larger than it should be?

Originally Posted by oogabooga

It looks like you may have 16-bit ints as well.
sizeof() actually doesn't return the number of bytes, but the number of chars.
One last piece of code. Please try this:

Code:

#include <stdio.h>
#include <limits.h>

int main() {
    printf("%d %d\n", INT_MIN, INT_MAX);
    return 0;
}

This code yields:

-32768 -1

So my Max int is -1? I may be a novice with C, and correct me if I'm wrong, but that seems like total nonsense.

Also, returning sizeof(struct glog) yields 44 like you say, yet its my actual file size that says 88 bytes (just a simple windows text file). However when I just count with my fingers and toes all the bytes that should be in the struct, I get 80.

But now that you have mentioned the 16 bit char being an architectural design, it makes sense. I have a total of 8 'char' types in my struct, so I was expecting those to only hold up 1 byte each. But it seems instead of the 80 I expect when I count, I get 88 in the final file size (i.e. the chars are double the size I expected as the theory is going).

Whether that makes sense or it doesn't, the problem still remains that I need to find a way to cut down on my data usage for this file I am writing. If its true that my char's are 16 bit types in my architecture, is there any way through C that I can possibly define a macro or something along those lines, to create a legitimate 8 bit type to replace my chars with?

Originally Posted by oogabooga

If he really needs to save space, he could probably manually pack two characters into a single 16-bit char.

Could you elaborate on this idea a bit? I get it at a high level and I think if I come up with the right implementation, there should be no big problem with doing this (will be a lot more annoying than the original 'fwrite(glog)' I thought I was going to get away with). But how can something like cutting two 16 bit types in half and sticking them together work as far as code?

Originally Posted by stahta01

@Rath: Try using unsigned to print

Code:

printf("%u %u\n", INT_MIN, INT_MAX);

This code yields:

32768 65535

so it does seem that yes, my integers are 16 bits in size whether they're signed or unsigned. Hm. I don't see why this architecture makes sense from a design standpoint, maybe it was designed to use assembly and get more low level? I would assume it would incorporate fairly traditional standard types though.

@oogabooga, thank you for that implementation. I have thought on it and it seems like if worst comes to worst and I absolutely cannot, for some reason, create a simple 1 byte data type easily on this architecture I can at the very least do a few quick shift operations before my write/read and not be eating up too many cycles on the system in the process. Just going to get a little hairy keeping track of things like 'the first 8 bits of my 16 bit char are for minutes of Time1, 2nd are Time2" etc for all these chars I have floating around

Originally Posted by oogabooga

It doesn't look like you'll be able to create anything but 16-bit types on that architecture. It's a 16-bit digital signal processor, and that's that. The reason for the restriction is to simplify and thus speed up the hardware.

Perhaps the limit on your file size is unrealistic.

I believe so too, alas I am a mere intern and would prefer to get it to spec rather than ask for a change in requirements on my first project

And I beleive you are rightabout the DSP core limitation. I have been scouring documentation for the past few hours to try and find a place where it lists in the spec that both chars and ints default to 16 bit types for this processor, and it says exactly that. Bitshifting solution it is. Thank you very much for your help.