Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Next revision Both sides next revision | ||
soc:2009:oremanj:journal:week5 [2009/06/26 21:47] rwcr |
soc:2009:oremanj:journal:week5 [2009/06/26 21:48] rwcr |
||
---|---|---|---|
Line 137: | Line 137: | ||
This is rather messy, of course; the fewer symbols with an implicit "might-be-NULL" attached the better. But for fairly tightly-coupled source files that need to be separated for size reasons, one or two weak functions can provide an excellent interface between the two. | This is rather messy, of course; the fewer symbols with an implicit "might-be-NULL" attached the better. But for fairly tightly-coupled source files that need to be separated for size reasons, one or two weak functions can provide an excellent interface between the two. | ||
- | While we're in the Cool Linker Tricks department, there's also something called a "weak alias", which serves a completely different purpose: providing one implementation of an API function while allowing it to be superseded without complaint by another object file. I haven't seen anything in gPXE that really needs this, but to give an example of how it //could// be used, gPXE core defines a simple ''memcpy()'' function that doesn't know about any architecture-specific optimizations, but only declares its prototype if the preprocessor macro ''_\_HAVE_ARCH_MEMCPY'' hasn't been defined by architecture-specific includes; that allows architecture-specific string functions to be used instead, using either ''#define'' or an inline implementation, but no symbol can be named ''memcpy'' because the linker would complain. A way around that would be: | + | While we're in the Cool Linker Tricks department, there's also something called a "weak alias", which serves a completely different purpose: providing one implementation of an API function while allowing it to be superseded without complaint by another object file. I haven't seen anything in gPXE that really needs this, but to give an example of how it //could// be used, gPXE core defines a simple ''memcpy()'' function that doesn't know about any architecture-specific optimizations, but only declares its prototype if the preprocessor macro ''%%__HAVE_ARCH_MEMCPY%%'' hasn't been defined by architecture-specific includes; that allows architecture-specific string functions to be used instead, using either ''#define'' or an inline implementation, but no symbol can be named ''memcpy'' because the linker would complain. A way around that would be: |
/* in core string code */ | /* in core string code */ | ||
void * core_memcpy ( void *dest, const void *src, int len ) { | void * core_memcpy ( void *dest, const void *src, int len ) { |