struc problems

[Spike]

Hi I'm using GCC (and NASM) to send over a asm table...

BootDrv db 0
BIOS_Mem_Map_Entries dd 0
APM_Status db 0
APM_Major_Version db 0
APM_Minor_Version db 0
APM_Code_Base dd 0
APM_Data_Base dd 0
APM_Data_Length dd 0
APM_Code_Length dd 0
VESA_Struct_Start:
;VESA
VESASignature db 'VESA'
VESAVersion dw 0
OemStringPtr dd 0
Capabilities dd 0
VideoModePtr dd 0
TotalMemory dw 0
;VBE2
OemSoftwareRev dw 0
OemVendorNamePtr dd 0
OemProductNamePtr dd 0
OemProductRevPtr dd 0
VBE2_reserved times 222 db 0
VBE_OemData times 256 db 0
VESA_ModeInfo dd 0
VESA_Mode_Counter dw 0
VGA_Mode_Counter dw 0
VGA_ModeInfo dd 0
Graphics_Mode_Choosen db 1
Graphics_SubMode_Choosen db 0
TimerLoop dd 0
Current_X dw 0
Current_Y dw 0

....to a C struc...

typedef struct BIOSInfo
{
BYTE BootDrv;
ULONG BIOS_Mem_Entries;
BYTE APM_Status;
BYTE APM_Major_Version;
BYTE APM_Minor_Version;
ULONG APM_Code_Base;
ULONG APM_Data_Base;
ULONG APM_Data_Length;
ULONG APM_Code_Length;
//VESA Struct Start
BYTE VESA_Signature[4];
USHORT VESAVersion;
ULONG OemStringPtr;
ULONG Capabilities;
ULONG VideoModePtr;
USHORT TotalMemory;
//VBE2 tillägg
USHORT OemSoftwareRev;
ULONG OemVendorNamePtr;
ULONG OemProductNamePtr;
ULONG OemProductRevPtr;
BYTE VBE2_reserved[222];
BYTE VBE_OemData[256];
ULONG VESA_ModeInfo;
USHORT VESA_Mode_Counter;
USHORT VGA_Mode_Counter;
ULONG VGA_ModeInfo;
BYTE Graphics_Mode_Choosen;
BYTE Graphics_SubMode_Choosen;
ULONG TimerLoop;
USHORT Current_X;
USHORT Current_Y;
}BIOSInfo;

.... but for some reason:

BIOSInfo *BIOS_Info_Pointer = Get_ASM_Params();
ScreenMode[0] = BIOS_Info_Pointer->Graphics_Mode_Choosen;
ScreenMode[1] = BIOS_Info_Pointer->Graphics_SubMode_Choosen;

ScreenMode[0] isn't equal to 1 (Graphics_Mode_Choosen) and ScreenMode[1]
isn't equal to 0 (Graphics_SubMode_Choosen).

Can anybody give me a hint on what's wrong?

btw:

_Get_ASM_Params:
lea eax,[BootDrv]
ret

TIA!

 

[Mark A. Odell]

Hi I'm using GCC (and NASM) to send over a asm table...

Have you read you compiler documentation about packing structs? C
compilers can add padding bytes after the first element of a struct.

 

[Spike]

no I haven't... where can I find information about if GCC padds struc:s?

//SPike

 

[Alex Fraser]

Have you read you compiler documentation about packing structs? C
compilers can add padding bytes after the first element of a struct.

After the first? There can be padding after any member (for some reason I
don't understand, most people say "between members and after the last
member").

Alex

 

[Mike Wahler]

no I haven't... where can I find information about if GCC padds struc:s?

Um, the GCC documentation?

-Mike

 

[Spike]

yes I know that. But I was hoping you know where in the manual or if you
knew the answer.

//SPike

 

[William Ahern]

After the first? There can be padding after any member (for some reason I
don't understand, most people say "between members and after the last
member").

Both are other ways of saying that padding can occur anywhere except before
the first element, since a pointer to the first element of a struct must
also be a pointer to that struct and vice versa.

 

[Alex Fraser]

Both are other ways of saying that padding can occur anywhere except
before the first element, since a pointer to the first element of a
struct must also be a pointer to that struct and vice versa.

OK, I think Mark's description was unclear. The two I gave are equivalent to
each other and equally clear IMO, but "between members and after the last"
seems pointlessly long-winded.

Alex

 

[Default User]

no I haven't... where can I find information about if GCC padds

struc:s?


1. Don't top-post. Your replies belong following or interspersed with
quoted material.

2. Implementation-specific questions should be directed towards an
implementation-specific newsgroup. gnu.gcc.help comes to mind.



Brian

 

[Lawrence Kirby]

Both are other ways of saying that padding can occur anywhere except before
the first element,

True, although "after the first element of a struct" could be interpreted
as "only after the first element of the struct", so it is ambiguous.

since a pointer to the first element of a struct must
also be a pointer to that struct and vice versa.

This is incorrect. A pointer to a struct may be *converted* to a pointer
to the type of the first member of the struct and the result will be a
pointer to the first member of the struct, and vice versa. This is
insufficient in itself to disallow padding before the first member
because there is nothing to prevent the conversion operation making the
appropriate adjustment for padding. C has a separate requirement that
there be no padding before the first member.

Lawrence

 

[Mark A. Odell]

OK, I think Mark's description was unclear.

Unclear maybe but not wrong:

struct Foo
{
int a;
char b;
short c;
};

"compilers can add padding bytes after the first element"

So, the compiler can add padding bytes after 'a', but not before, after
'b', and after 'c'. Still sounds like my original statement.

 

[Mark A. Odell]

True, although "after the first element of a struct" could be
interpreted as "only after the first element of the struct", so it is
ambiguous.

I'll give you that but in the absense of a constraint, e.g. "only after"
why would you think to add such a constraint?

 

[Mark A. Odell]

yes I know that. But I was hoping you know where in the manual or if you
knew the answer.

Just search for the word "pack"!

 

[Lawrence Kirby]

....


I'll give you that but in the absense of a constraint, e.g. "only after"
why would you think to add such a constraint?

I only suggest that use of English is loose enough to allow that as a
possible interpretation.

Lawrence

 

[Mike Wahler]

yes I know that. But I was hoping you know where in the manual

Sorry, no, I won't read the manual for you.

or if you
knew the answer.

If I need the answer, I know where I can find it.
So do you.

-Mike

 

[Mark A. Odell]

I only suggest that use of English is loose enough to allow that as a
possible interpretation.

Indeed.