This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: B20: egcs: Questions (Structures, inline assembly, comments, unnamed unions)


On 01-Dec-1998, Jonathan Pryor <jonpryor@vt.edu> 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 <stdio.h>
> 
> 	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.
> <sarcasm>In Microsoft's great genious</sarcasm>, they 
> decided to insert inline assembler into their headers
> (yech!), such as this (from <winnt.h>):

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
>    <winnt.h> 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 <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]