1

If you were to declare something like:

struct MyStruct
{
   int field1;
   int[] field2;
   int field3;
}

field 2 is actually a pointer to an array, rather than being the array itself. So MyStruct retains a size of 3 bytes. I wonder if there is a way to do something similar, except that field2 should be the array itself and not a pointer.

Obviously you could do this with just an array, but my final goal is to be able to have different types of varying size in the aforementioned structure; which would require padding (which I do not want).

Is this possible at all?

Makogan
  • 8,208
  • 7
  • 44
  • 112
  • 1
    You don't show definitions for the three structure types, but as long as you've got them defined, you can create a union and the compiler is obliged to follow the rules you say you want it to follow. – Jonathan Leffler May 28 '17 at 00:46
  • 3
    "such that all fields appear contiguously in memory in the order that they were declared"-- there may be padding in the `struct`. [Is this an XY problem?](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) – ad absurdum May 28 '17 at 00:48
  • Are you attempting to write this struct to disk or to a socket? If so, you need to send/save each field individually instead of the struct as a whole. – dbush May 28 '17 at 01:02
  • Given your update, what you seek cannot be done in C. Or, at least, it requires chicanery and trickery. All else apart, the `oNum` member must be at a fixed offset, but you're demanding that it appears at different offsets depending on the value stored in the 'union'. – Jonathan Leffler May 28 '17 at 01:07
  • Yes, what you describe is exactly what I would need. So it seems I have run into a limitation of the language? – Makogan May 28 '17 at 01:10
  • 1
    I would suggest you read the question @DavidBowling linked to very carefully before you decide that what you need is really what you imagine it to be. It is unlikely that the underlying problem you are facing has never been come across or solved before, but it certainly hasn't been solved in the way that you proposed. – Hiko Haieto May 28 '17 at 01:13
  • 2
    As mentioned before, this smells strongly of an XY problem. **Why** do you think you need the struct to always be its minimum size? What are you **really** trying to do? There is probably a better way of approaching your issue. – dbush May 28 '17 at 01:15
  • The structures contain messages intended for the armv8 videocore of a raspberry pi model 3, depending on the nature of the message the size varies, but the videocore expects the data to follow this convention: https://github.com/raspberrypi/firmware/wiki – Makogan May 28 '17 at 02:33
  • 1
    This really should have been part of your question from the start. Basically, this was a networking and raspberry pi question, and has next to nothing to do with gcc. Update your question to better reflect the actual problem you're trying to solve, and then we can better attempt to address that. – Hiko Haieto May 28 '17 at 04:20
  • Why is this tagged [assembly]? What does this have to do with assembly language? You are clearly writing in and targeting C. – Cody Gray - on strike May 28 '17 at 07:15
  • @CodyGray It has to do with assembly because of the problem that is actually being working on, not the problem that was asked. This has not been clarified yet, but it appears to be focused on low level networking code to interface with a device through the raspberry pi firmware. Code for firmware and embedded devices often involves intermixing low level (typically assembly) code, as you can see if you follow the github link above. – Hiko Haieto May 28 '17 at 16:13

1 Answers1

1

The union will be at least as large as the largest item in the union, no smaller. If you are currently using one of the smaller items, it will not shrink the size of the union or the outer struct it is part of. However, the items before and after the union will still be safe and physically present before and after the memory used for the union, even if the memory currently being used by them do not exactly touch. This question shows an example of precisely how you can create such a union.

In response to the update, if the outer struct truly must be the same size regardless of the union, then the best you could hope to do is have a pointer to the union contents instead of the union itself. The union would still not be the "minimum" size though. Otherwise, do as dbush suggests and have three outer structs, with no use of union at all.

Hiko Haieto
  • 433
  • 2
  • 9
  • See, the problem is that there cannot be any added information to that structure it has to always be the minimum size to contain the info – Makogan May 28 '17 at 00:57
  • 2
    It is not possible to have the union always be the "minimum size" - this is not an implementation-specific thing either. Unions are designed to change between which member of the union it's representing, every time it's written to. If at that moment you use it as a different member, it now represents that member. If its size was the minimum size and you stored a larger member to it, you'd clobber everything that came after. Can you elabourate on why you think it has to be the minimum size possible? – Hiko Haieto May 28 '17 at 01:01
  • 2
    @Makogan Then you need 3 separate outer structs, each with its own inner struct. There's no way to dynamically grow or shrink depending on which member of a union you happen to be using. – dbush May 28 '17 at 01:01
  • that makes me sad :C – Makogan May 28 '17 at 01:12