Hello Charles, Am Sonntag, 3. Oktober 2004 um 06:49 schriebst du:
> Gerrit P. Haase wrote: > Well, you have a struct that is const, so it "never changes" and new gcc > puts the whole struct into .rdata >> static const >> struct poptOption cl_libIDL_callback_options[] = { >> [snip] > But the important part is that INSIDE the struct, one of the > "initialized fields" contains the address of a variable. In this case, > although you didn't show it, it's the address of the variable into which > popt is supposed to store the argument for one of the command line > options. E.g. (going from memory) > struct { > option = "--bob" > short_option = "-b" > type = POPT_INTEGER > value = &my_variable <<<<---- right here > helpstr = "blah blah blah" > }; > So, what's supposed to happen (from popt's perspective) is that the user > types "--bob 12" and popt will parse the "12" and store it into my_variable. > However, my_variable is a DATA export from your DLL (it has to be an > export, so that popt can "see" it). > But the address of DATA exports from DLLs is unknown at link time. The > Windows Runtime Loader has special code (coupled with > declspec(dllexport)/declspec(dllimport)) to fixup this address at > runtime. To avoid declspec hell, on cygwin and mingw, the platform, > compiler and linker cooperate to do something similar, fixing up the > address at runtime to be a function pointer to a trampoline, which > eventually "makes it all work". > But it is necessary, in both "normal" windows and cygwin's > pseudo-runtime-reloc, to UPDATE the address stored in the struct for > &my_variable. > But the struct is in .rdata and its contents cannot be changed at runtime. > Better? Yes, cool. Now I think I can distinguish between 'wrong' and valid const struct definitions. May I consider using 'const' for structs which are not really constant (i.e. containig a variable) as harmful? Gerrit -- =^..^=