This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] fix include files to support non-GNU compilers
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Mikulas Patocka <mpatocka at redhat dot com>
- Cc: Mike Frysinger <vapier at gentoo dot org>, Richard Henderson <rth at twiddle dot net>, Andreas Schwab <schwab at suse dot de>, <libc-alpha at sourceware dot org>
- Date: Mon, 16 Mar 2015 23:53:49 +0000
- Subject: Re: [PATCH] fix include files to support non-GNU compilers
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LRH dot 2 dot 02 dot 1408311629460 dot 27738 at file01 dot intranet dot prod dot int dot rdu2 dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1409011646360 dot 14636 at digraph dot polyomino dot org dot uk> <alpine dot LRH dot 2 dot 02 dot 1409011849480 dot 311 at file01 dot intranet dot prod dot int dot rdu2 dot redhat dot com> <20150307210148 dot GO12857 at vapier> <alpine dot LRH dot 2 dot 02 dot 1503161237500 dot 15105 at file01 dot intranet dot prod dot int dot rdu2 dot redhat dot com>
On Mon, 16 Mar 2015, Mikulas Patocka wrote:
> The problem here is that a stray semicolon at top level is invalid - it is
> accepted by gcc, but it is invalid by the C standard and not accepted by
> other compilers.
>
> So if you do empty definition "#define define __MATHDECL_2(type,
> function,suffix, args, alias)" and then use it this way "__MATHDECL_1
> (int,__isinf,, (_Mdouble_ __value));", you get a stray semicolon and
> compiler failure. You need to declare something in the __MATHDECL_2 macro
> - so the patch declares an empty structure (prefixed by underscore, so it
> should not clash with user programs).
>
> An alternate solution would be to drop the semicolons from the users of
> MATHDECL macro and move them to the MATHDECL macro itself, but it would
> make the patch bigger.
I think you need to go a few steps back and write a self-contained
explanation of what the various macros involved do and what you are trying
to achieve, and the rationale for the approach you chose for the fix.
I'd say that if redirections aren't supported you should aim for the macro
expansions for long double to look just like those for float and double
(i.e. no redirections, just declaring each function with and without the
__ prefix). Is there some reason that is hard to achieve?
--
Joseph S. Myers
joseph@codesourcery.com