I see them a lot in UEFI code:
normal C calling constructs:
<return type> <function name> (<param1 type> <param1>, <param2 type> <param2>,....<paramN type><paramN>)
{
<function body>
}
in UEFI code, I see a lot:
EFI_STATUS EFIAPI <function name> (IN OUT <param1 type><param1>)
{
<function body>
}
Here I see EFI_STATUS is a return type, but how about EFIAPI, IN and OUT keywords?
May be I have grab my C primer that is collecting dust in my shell to see anything is there.
what are those constructs?
-
- Member
- Posts: 396
- Joined: Wed Nov 18, 2015 3:04 pm
- Location: San Jose San Francisco Bay Area
- Contact:
what are those constructs?
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
Re: what are those constructs?
That's easy. IN, OUT, there might be also their combination are just a convenient way to hint you of a purpose of this parameter - are they input for a function, output or both. Microsoft has a lot heavier system for this. They even call it somehow, forgot it.
Above things defined just as empty macros. For example:
#define IN
As of EFIAPI, it is a calling convention (CC) specification marker. UEFI requires all defined by the specification functions to follow the convention defined by UEFI. If your compiler supports several CC, there should be one compatible with UEFI's. And then you might bind EFIAPI specifier to the compiler's keyword for that CC. Something like this:
#if defined(___cool_n_free_as_in_beer_and_vodka_compiler_blablabla)
#define EFIAPI ___declspec(CALLING_CONVENTION_COMPATIBLE_WITH_UEFI)
#elif defined(some_else_cool_n_free_compiler)
#define EFIAPI XXX
#endif
That said, mostly EFIAPI defined as an empty macro as well.
Speaking by my own experience. So far I am working with MIPS architecture, and since UEFI doesn't have this architecture included and thus, - doesn't have any CC specification for it, I chose it by myself. I chose O32 calling convention it's good and simple, everything needed. Since it's a default CC for GCC I use, I defined EFIAPI as a plain macro.
An excerpt from my own Uefi.h file, as an example:
Above things defined just as empty macros. For example:
#define IN
As of EFIAPI, it is a calling convention (CC) specification marker. UEFI requires all defined by the specification functions to follow the convention defined by UEFI. If your compiler supports several CC, there should be one compatible with UEFI's. And then you might bind EFIAPI specifier to the compiler's keyword for that CC. Something like this:
#if defined(___cool_n_free_as_in_beer_and_vodka_compiler_blablabla)
#define EFIAPI ___declspec(CALLING_CONVENTION_COMPATIBLE_WITH_UEFI)
#elif defined(some_else_cool_n_free_compiler)
#define EFIAPI XXX
#endif
That said, mostly EFIAPI defined as an empty macro as well.
Speaking by my own experience. So far I am working with MIPS architecture, and since UEFI doesn't have this architecture included and thus, - doesn't have any CC specification for it, I chose it by myself. I chose O32 calling convention it's good and simple, everything needed. Since it's a default CC for GCC I use, I defined EFIAPI as a plain macro.
An excerpt from my own Uefi.h file, as an example:
Code: Select all
/* ABI specification */
#define EFIAPI /* for mips32 it's o32 */
#define NULL ((PVOID)0)
#define IN
#define OUT
#define OPTIONAL
#define CONSTANT const
#define CONST const
-
- Member
- Posts: 396
- Joined: Wed Nov 18, 2015 3:04 pm
- Location: San Jose San Francisco Bay Area
- Contact:
Re: what are those constructs?
thx, looks like these are something i have never bothered to deal with, will look into it.zaval wrote:That's easy. IN, OUT, there might be also their combination are just a convenient way to hint you of a purpose of this parameter - are they input for a function, output or both. Microsoft has a lot heavier system for this. They even call it somehow, forgot it.
Above things defined just as empty macros. For example:
#define IN
As of EFIAPI, it is a calling convention (CC) specification marker. UEFI requires all defined by the specification functions to follow the convention defined by UEFI. If your compiler supports several CC, there should be one compatible with UEFI's. And then you might bind EFIAPI specifier to the compiler's keyword for that CC. Something like this:
#if defined(___cool_n_free_as_in_beer_and_vodka_compiler_blablabla)
#define EFIAPI ___declspec(CALLING_CONVENTION_COMPATIBLE_WITH_UEFI)
#elif defined(some_else_cool_n_free_compiler)
#define EFIAPI XXX
#endif
That said, mostly EFIAPI defined as an empty macro as well.
Speaking by my own experience. So far I am working with MIPS architecture, and since UEFI doesn't have this architecture included and thus, - doesn't have any CC specification for it, I chose it by myself. I chose O32 calling convention it's good and simple, everything needed. Since it's a default CC for GCC I use, I defined EFIAPI as a plain macro.
An excerpt from my own Uefi.h file, as an example:Code: Select all
/* ABI specification */ #define EFIAPI /* for mips32 it's o32 */ #define NULL ((PVOID)0) #define IN #define OUT #define OPTIONAL #define CONSTANT const #define CONST const
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails