> > The compiler must obey the C standard and this is the reasonable way to >> > make it so. > > > Yes, it is indeed a very reasonable and elegant way but maybe still not > the only choice a C compiler could make. Say there is certain C compiler > tool chain implementation named XCC: > > 1. XCC obey the Sys V ABI when calling extern C functions (same as GCC > does). > 2. XCC always use a self defined calling convention named > XCC_CALL_For_Static_Functions to call the static C functions. > 3. The XCC's XCC_CALL_For_Static_Functions is completely different from > the calling sequence defined in the Sys V ABI. > 4. Here is how XCC generated executable binaries (say XBIN for example) > calling static C functions: > 4.1. XBIN always maintain a set of all the extern functions' address, and > the name of this set is "XSET". > 4.2. When doing function call via any variable function pointers, it would > check the XSET, if the function pointer pointing to an extern function it > would choose to use the Sys V ABI Calling Sequence, otherwise the > XCC_CALL_For_Static_Functions would be used. > 4.3. For the calling of constant function pointers, XCC will try its best > to optimize the process described in 4.2 above. > 5. XCC obey the Sys V ABI and C specs. > Suddenly appear to me that it would be much tricky if some C library choose to export an extern C function pointer variable. I didn't notice such situation a moment ago.
