From: fjh AT cs DOT mu DOT OZ DOT AU (Fergus Henderson) Subject: Re: B20: egcs: Questions (Structures, inline assembly, comments, unnamed unions) 3 Dec 1998 08:35:17 -0800 Message-ID: <19981203174957.15452.cygnus.gnu-win32@mundook.cs.mu.OZ.AU> References: <000201be1d73$64e6bb80$246a52c6 AT balthasar DOT campus DOT vt DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Jonathan Pryor Cc: "gnu-win32 Mailing List (E-mail)" On 01-Dec-1998, Jonathan Pryor wrote: > I'm trying to get the latest Microsoft Platform SDK headers > to compile under egcs-2.91.57, and I came across volumes of > code that seem to generate errors... :-) .... > First are structures that contain arrays of unspecified size, > e.g.: > > #include > > typedef struct _TEST { > short Pad; > unsigned char Format[]; > } TEST; > > int main (int, char **) { > return 0; > } > > I've looked in Stroustrup (3rd edition) to see if the above > syntax is legal, but found nothing. Thus, some questions: > * _Is_ it legal? No. Not in standard C (C89) or standard C++. It is however allowed by the draft new C standard, C9X. > * Is there any type of workaround that *doesn't* require > changing the code? Yes, change the compiler instead. Since this feature is included in C9X, I'm sure the egcs developers would be happy to accept a patch to make their C and C++ compilers support it, even though this is not required by the current C or C++ standards. It is possible that someone may have done this already, so it's worthwhile asking them first. > ---- > Second is the issue of code containing inline assembler. > In Microsoft's great genious, they > decided to insert inline assembler into their headers > (yech!), such as this (from ): There's nothing wrong with doing that, the GNU C library does it too. However, any such source code should be guarded with `#ifdef's that ensure that the compiler supports it. So the problem is the lack of such #ifdefs, not the use of inline asm as such. > I looked up the g++ `asm' documentation in the man pages, and > was rather confused... There is some much better documentation on this floating around on the WWW somewhere -- unfortunately I don't have the URL on hand. but you could try a WWW search. I believe it was posted to one of the Linux kernel mailing lists. > Thus, some questions: > * why does g++ uses the syntax it currently uses > (though this is mostly out of curiosity). It provides the compiler with more information, which allows it to optimize code containing inline asm much better. > * is there any way (without modifying the files) to > get around this inline assembler? (Actually, there is a > way -- set the _M_ALPHA pre-processor macro, which causes > to think it's running on an Alpha, thus it simply > uses macro's for the functions, as Alpha has native support > of 64-bit types... But this still leaves the first question > about the structures.) Be careful that setting _M_ALPHA doesn't have any other side-effects. > #define _VARIANT_BOOL /##/ Ugh. That code is not portable. The right way to fix such code is something like #ifndef HAVE_BOOL _VARIANT_BOOL bool; #endif where HAVE_BOOL is defined appropriately. -- Fergus Henderson | "Binaries may die WWW: | but source code lives forever" PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 3 | -- leaked Microsoft memo. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".