Re: gettext patches for cygwin #4: accessing fields of exported structs/arrays

[Bruno Haible]

Charles Wilson wrote:
> If that is true, then there is a bug in gcc (and not simply a platform
> insufficiency -- "you can't do X on platform Y").  If it can be done by
> g++ then it should also be done by gcc.

If you want to work on pushing this feature from g++ into gcc, I can
explain to you how g++ does it. Assume you have a variable defined in
a DLL,

     extern DLL_VARIABLE int option_x;

then gcc will know that it has to access this variable indirectly:

     #define option_x  *(__imp_option_x ())

Now if I have a declaration

     static const struct option long_options[] =
     {
       { "exclude", 0, &option_x, 'x' }
     };

The C compiler notices that &option_x is not of the type of constant
expressions allowed in initializers (linker constants or addresses or
differences between two addresses), and gives an error.

The C++ compiler notices that &option_x is the same as
__imp_option_x (), namely a runtime dependency, and generates code for

     static /*not const*/ struct option long_options[] =
     {
       { "exclude", 0, NULL /*filled later*/, 'x' }
     };

and a static "constructor" function that will do

     long_options[0].flag = __imp_option_x ();

Such "constructor" functions are also supported by gcc in C mode, through
__attribute__((__constructor__)). Therefore there is no fundamental
reason why gcc could not do the trick that g++ does.

> I'm not sure HOW g++ is able to finesse this issue, but it does so at
> the cost of ABI compatibility.  The old C-only gettext DLL had a C ABI;
> thus a DLL compiled by mingw was usable by intel, borland, or msvc
> compilers.  By introducing C++ compilation, you've wandered into the
> hell that is C++ ABI variation.

If you push the above g++ technique into gcc, I don't see any ABI
problems appear.

> Jeez, Bruno! You've erected a huge structure -- conditionals in
> Makefile.am, wrapper files whose sole purpose is to fool automake into
> generating C++ rules instead of C rules to compile certain files...all
> to get around an issue that has a simple fix, *already employed* for
> accesses to other variables:
>
> -----
> po-lex.[h|c]:
>
> /* But, we can't access member fields of structs that are exported
>     from DLLs on windows, so use the function calls not the macros */
>
> In other words, client code uses a function to access fields of structs
> in data exported by the DLL, instead of accessing the data directly.

There are four reasons why I chose the C++ wrapper files approach
instead of the solution that you are proposing:

1) The existing code is ANSI C. According to the principle "fix the
   broken code, not the correct code", it is the wrong place to
   modify po-lex.[h|c] because of problem that is in Woe32.

2) My changes are conceptually easy, i.e. they don't require insight
   in the program. Testing which files give an error when compiled in
   C mode is something a porting person can do without understanding
   the program.

3) In the process of making releases, Woe32 porting comes late before
   a release. With your approach, you have to expect that it is needed to
   turn a variable into a function, and other kinds of API changes.
   I hate to make such changes right before a release, because it means
   I have to restart testing on the other platforms.

4) Reliability: With my approach, I know that things work if they compile.
   Whereas your approach requires testing of the built executables in
   order to know whether there are still relocation problems remaining.

>   But still...I wonder if it is possible that, at some time in the
> future, g++ will start generating code similar to that currently
> generated by gcc, given identical input.  At that hypothetical point,
> your solution is back to square one.

You mean, gcc will start generating code that is as good as g++ now?
At that point, it will be easy to remove the "scaffolding" - as you call
it - from the Makefiles. And I'll have no changes to make to the actual
source code. Whereas with your approach, I would have to turn back
indirect-access functions into variables.

Bruno