wrong evaluation of the compiler??... Very rare error

Hi,

Hans, you are right, but, don't think my phrase was as bad as you said.. but, I will try to ask the questions better.

By the other hand memory is not important today, but, in some cases 3 or 4 more bytes when all data is 10 bytes in cost sensitive applications can be a problem.

Thanks.

Hi,

Hans, you are right, but, don't think my phrase was as bad as you said.. but, I will try to ask the questions better.

By the other hand memory is not important today, but, in some cases 3 or 4 more bytes when all data is 10 bytes in cost sensitive applications can be a problem.

Thanks.

"By the other hand memory is not important today, but, in some cases 3 or 4 more bytes when all data is 10 bytes in cost sensitive applications can be a problem."

You are not likely to find a chip with only 10 bytes of data, so you will then not get 30% or 40% of filler bytes. So a single struct can be used without pack.

And if you need to store 1000 structures, you have enough that it is meaningful to see it as a database and create a "read_record()" and "wrtie_record()" that handles pack/unpack.

Hi,

When you have to store 10 bytes every 1 hour and the program must write data for some month, 3 or 4 bytes is very important, is the difference berween store 40 days or 70 days using a memory lime M24C128... You can place a larger memory or two memories, but, when is a cost sensitive application, you cant...

In that case, as already discussed, you should not be writing structures - you should have read() and write() functions to access the storage as a "stream"...

If I write a data logger, where memory is important, I would probably even check if I need 8 + 16 bits or maybe just 5 + 12 bits.

I might even, depending on type of sample, see if I can have one bit of data represent if following record is having absolute or relative values. Storing temperatures as deltas can save a lot of memory space.

But trying to use raw C structs for binary storage on a memory media is just plain silly. It's a great example of walking the wrong path. Especially so if that memory is removeable and should potentially be read by another device.

The language don't have a standard for packing structures just because it isn't a good way to solve the kind of problem you are trying to solve.

Time to take two steps back and switch to a real solution. A solution that is not depending on compiler flags, pragmas or other tricks.

By the way - your 8-bit value is named "Hora". That would be "hour". If your logger do record one sample every hour, you don't have a need to store any hour value in the sample. So 3 bytes suddenly became 2 bytes. And if the 16-bit value can never be larger than what fits in 15 bits, you could use one bit as "flag" to store a hour jump in case the device has been turned off and there is a jump in hours since previous sample recorded.

In the end, your packed data would probably waste a lot of memory, if memory really are important.

This was an example to solve the problem, in my case the sturcture is more complex and hard to explain... Is curious that the people try to say absolute solutions without knowing at all the question like use "write" o r "read" like stream or other "solutions" posted here without know other things related to the device or its operation... The problem is solved and this discusion have no sense now, anyway, thaks.

had I started this from scratch I would have created the struct the way i have done ever sice my first exposure to an "alignment critical" processor

I always make structs this way:
dwords
words
bytes

that way there never is an alignment issue

Erik

Since you didn't give any of those details, how could anyone else know them?!

Therefore, we discuss general principles - that can be applied in all cases.

"this discusion have no sense now"

Note that this is not a free consultancy service - it is an open discussion forum.

It seems that there are still issues worthy of discussion - even if not specifically pertinent to your particular application at this time.

"Is curious that the people try to say absolute solutions without knowing at all the question like use "write" o r "read" like stream or other "solutions" posted here without know other things related to the device or its operation.."

It is "curious" that the compiler must implement code to serialize read and write if you play with a packed structure. Which is a reason why the general recommendation is to not use a compiler-specific attribute to hide an issue in a way that fools other developers and can result in huge problems with concurrency etc.

It is "curious" that the normal solution is to explicitly call code that does the pack/unpack, where what happens is visible and can be debugged or potentially optimized depending on the specific needs.

That you did write the answer you did, indicates that you did not spend some time really thinking through the answers you have received. If you had, and didn't agree with some of it, you would have posted specific follow-up questions or "wouldn't this ..." comments instead.

Well, you are free to run into walls if that makes you happy. We don't care if you use problematic structures. We can suggest reasons to avoid doing it, but it is still up to you to ignore recommendations if you think maybe 3-digit years of experience isn't relevant.

Is curious that the people try to say absolute solutions without knowing at all the question like use "write" o r "read" like stream or other "solutions" posted here without know other things related to the device or its operation..

the usual reason for this is that the question was formulated in a vague way

Erik

The problem is solved

No, it's not. You only believe it is, solely based on picking exactly the wrong pieces of information out of the wealth you've been given.

and this discusion have no sense now,

You're wrong about that. Just because you refuse to learn something doesn't mean others can't.