What is the meaning of "unmanaged representation"?

[Korporal]

The documentation for FieldOffseAttribute refers to "unmanaged representation" of a struct. Can anyone explain precisely what this means? does the managed "representation" differ from the unmanaged? if so, then how and under what circumstances do these differ?

If one uses unsafe C# with a pointer to a struct that has this attribute, then are the offsets of member fields always the same as those specified by the attributes? if so then should we adjust the wording of the documentation to avoid any misunderstanding by the use of "managed" and "unmanaged" representations?

See also: #100621 (reply in thread)

[jkotas]

"unmanaged representation" of a struct. Can anyone explain precisely what this means?

It is explained in https://learn.microsoft.com/en-us/dotnet/framework/interop/interop-marshalling

does the managed "representation" differ from the unmanaged?

Yes, the managed representation can differ from unmanaged representation. Types with identical managed and unmanaged representation are called blittable types: https://learn.microsoft.com/en-us/dotnet/framework/interop/blittable-and-non-blittable-types .

[Korporal]

What do you need the offset for, given that you know that it is always going to be 16?

The offset appears in address calculations, when we have the address of some block the address of the user's data region for that block is the address of the block + that offset value. Likewise if we have a pointer passed in from the user (as in say a Free operation) we can get the address of the associated block by subtracting the offset from that user's pointer.

I wanted the 16 to be computed, derived from the type in some way, so for example if we were to add a field to the header area or something, I wanted to not have to adjust that 16 manually, this is why I was seeking something like offsetof akin to sizeof.

This does not account for an alignment padding that may be inserted between the struct and the field in the general case. Depends on how general and robust you want this pattern to be.

Exactly, this is why I was seeking a way to impose a layout, prevent the situation where we were unsure of exactly how stuff will be laid out. I think FieldOffsetAttribute can serve this purpose now that you clarified the matter of 'blittable". although we must still hard code a literal number here.

[CyrusNajmabadi]

I wanted the 16 to be computed, derived from the type in some way, so for example if we were to add a field to the header area or something, I wanted to not have to adjust that 16 manually, this is why I was seeking something like offsetof akin to sizeof.

You could use a source-generator which generates these constants for you. Or you can have it generate the bodies of the helpers that give this information back to you.

[CyrusNajmabadi]

although we must still hard code a literal number here.

True, though that's only a one time thing. And, it would be trivial to write an analyzer that ensures that those values are correct.

Alternatively, you could just define your layout in some other additional-file schema that you add to roslyn, and have roslyn just generate everything for you (the structs, the fields, the attributes, etc.). Or, make your type partial, and use roslyn source-gen to emit the fields/attributes into another partial part.

[jkotas]

You could use a source-generator which generates these constants for you.

This does not work for the same reason C# compiler is not able to replace sizeof with a constant in the general case. The source-generator would have to be aware of all architecture and platform specific field layout rules.

this is why I was seeking a way to impose a layout, prevent the situation where we were unsure of exactly how stuff will be laid out

Imposing the layout has the same problems as just hardcoding a constant. If you add or remove fields, you can end up with a silent mismatch between the imposed layout and the actual layout. Moreover, this mismatch may be present on a subset of architectures and platforms only.

[CyrusNajmabadi]

@jkotas I believe that @Korporal has a fixed architecture he is targeting. He has stated that this is for a particular controller. that said, i've asked for clarification if it truly is just a single architecture, or multiple ones, but i haven't heard back yet.

[Korporal]

Imposing the layout has the same problems as just hardcoding a constant. If you add or remove fields, you can end up with a silent mismatch between the imposed layout and the actual layout. Moreover, this mismatch may be present on a subset of architectures and platforms only.

Well this isn't a major concern for me, there are evidently several ways to do this and the code runs absolutely fine. But there does seem to be a bit of a problem in general with either the language or the runtime. The memory layout might be independent of platform altogether (like say a COFF or ELF file structure).

If one writes some C# API to consume a COFF or ELF or GIF or other files made of intricate packed structures, one will want that API to always "see" the file's content correctly no matter what platform we are running on.

The real question here is how can one write C# code that might run on any platform, yet be confident it will honor a memory layout contract.

It seems (if I've understood everyone) that specifying an explicit layout with specific offset attributes will always work (if the structs are blittable, which in my case they will always be) leaving aside issues of "endianess". The reason I've been pursuing this I had conflicting advice from others, some one way was good others said it wasn't and I should do it another way and so on, I just wanted to get complete clarity on how this currently works.

[CyrusNajmabadi]

The real question here is how can one write C# code that might run on any platform, yet be confident it will honor a memory layout contract.

Tanner answered this here: #100621 (reply in thread)

You can see how this works by looking at the source for PEHeaders, which I linked to in that thread as well: #100621 (reply in thread)

[CyrusNajmabadi]

, I just wanted to get complete clarity on how this currently works.

IN the future, it would be helpful to respond to the questions given to you about your problem space. How you answer will adjust the answers. For example, what might work fine in a subset of cases may not work in all scenarios. When there is information missing (esp. when asked for) it makes it hard to answer a question fully, and it can lead to the problem you mentioned, where information can seem contradictory.

[Korporal]

, I just wanted to get complete clarity on how this currently works.

IN the future, it would be helpful to respond to the questions given to you about your problem space. How you answer will adjust the answers. For example, what might work fine in a subset of cases may not work in all scenarios. When there is information missing (esp. when asked for) it makes it hard to answer a question fully, and it can lead to the problem you mentioned, where information can seem contradictory.

@CyrusNajmabadi, Consider 0x4675636B204F6666 in an MCU vector register as an example, to fully understand meaning, one needs information about alignment and padding and offsets.

[CyrusNajmabadi]

In that case, i think the suggestion i had would work. If it is the case that you are operating on a fixed set of platforms you can validate.