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

[Charles Wilson]

Bruno Haible wrote:
> Charles Wilson wrote:
> > Cygwin is a windows-ish platform, but doesn't #define WIN32.  Therefore
> > we must be sure to access fields of structs indirectly.
> >
> > 2005-11-20  Charles Wilson  <address@hidden>
> >
> >         * gettext-tools/src/plural-table.c (get_plural_table_entry):
> >         new accessor function
> >         * gettext-tools/src/msgfmt.c (check_plural): use
> >         get_plural_table_entry() accessor instead of plural_table[].
>
> Thanks for the patch. But I don't want to apply this: The gettext source
> code is fully valid ANSI C. I assume that the code works fine when
> configuring with --disable-shared, i.e. that it's a problem introduced
> by the structure of Woe32 DLLs? 

Yes.

> In this case, the workaround is to
> use g++ instead of gcc to compile the source code. This workaround
> works for the mingw32 platform and it is integrated into the gettext
> CVS at http://savannah.gnu.org/projects/gettext. (Look at the
> "if MINGW" conditionals in gettext-tools/src/Makefile.am.)
> It looks likely that this workaround would also work for the cygwin
> platform, since they share the same compiler and the same broken Woe32
> DLL architecture. I would love to have the same workaround for Cygwin
> than for mingw.

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.  But that's a side issue, to my 
horror at...

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.
-----

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.

I'm not really sure you're on solid ground, claiming this code is "fully 
valid ANSI C" -- which it very well may be -- if your workaround is to 
abandon the C compiler and use the C++ one instead!  If we're talking 
about "workarounds" for compilers that are not completely conforming 
(which building shared libs), why not a function/indirect access 
workaround?  Surely that's much simpler than this Rube Goldbergian 
scaffolding?

Granted, your changes address both the issue here, and the one addressed 
by my rdata patches (which really have two separate underlying causes). 
 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.

--
Chuck