[Bug libc/12153] New: use of keywords in macro definitions (e.g. void in assert) can make compilation fail

[Bug libc/12153] New: use of keywords in macro definitions (e.g. void in assert) can make compilation fail

[vincent+libc at vinc17 dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

           Summary: use of keywords in macro definitions (e.g. void in
                    assert) can make compilation fail
           Product: glibc
           Version: 2.11
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: vincent+libc@vinc17.org


While the following program is strictly conforming in C99, it cannot be
compiled due to the use of void in the assert() macro:

#include <assert.h>

int main (void)
{
#define void error
  assert(1);
#undef void
  return 0;
}

I get under Debian/unstable with glibc 2.11.2:

redef-void.c: In function 'main':
redef-void.c:6: error: 'error' undeclared (first use in this function)
redef-void.c:6: error: (Each undeclared identifier is reported only once
redef-void.c:6: error: for each function it appears in.)

Other macros may have a similar problem. I haven't checked.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions (e.g. void in assert) can make compilation fail

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-22 14:34:25 UTC ---
I think this is generally considered to be a bug in the C standard.  Given 
the explicit definition in the standard of how assert should be defined 
under NDEBUG it seems fairly clear that committee has never explicitly 
intended such usages to work; it's simply been so obviously a bug that 
no-one has felt the need to spend their time explicitly affirming that.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions (e.g. void in assert) can make compilation fail

[jakub at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

Jakub Jelinek <jakub at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com

--- Comment #2 from Jakub Jelinek <jakub at redhat dot com> 2010-10-22 14:55:11 UTC ---
Well, we could use something like
extern void *__assert_voidptr;

and (__typeof (*__assert_voidptr)) instead of (void) in __ASSERT_VOID_CAST
but it would be very ugly.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions can make compilation fail

[vincent+libc at vinc17 dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

Vincent Lefèvre <vincent+libc at vinc17 dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|use of keywords in macro    |use of keywords in macro
                   |definitions (e.g. void in   |definitions can make
                   |assert) can make            |compilation fail
                   |compilation fail            |

--- Comment #3 from Vincent Lefèvre <vincent+libc at vinc17 dot org> 2010-10-22 15:14:43 UTC ---
(In reply to comment #1)
> I think this is generally considered to be a bug in the C standard.  Given 
> the explicit definition in the standard of how assert should be defined 
> under NDEBUG it seems fairly clear that committee has never explicitly 
> intended such usages to work; it's simply been so obviously a bug that 
> no-one has felt the need to spend their time explicitly affirming that.

I agree for assert(), though the explicit definition may be seen itself as a
bug in the standard (in the sense: why should void be an exception to the
rule?). But it seems that <math.h> has similar problems, where the standard
doesn't give an explicit definition.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions can make compilation fail

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-22 15:22:51 UTC ---
On Fri, 22 Oct 2010, vincent+libc at vinc17 dot org wrote:

> I agree for assert(), though the explicit definition may be seen itself as a
> bug in the standard (in the sense: why should void be an exception to the
> rule?). But it seems that <math.h> has similar problems, where the standard
> doesn't give an explicit definition.

There's an example of a possible definition for fpclassify in 7.12.3.1#4 
that uses the keywords sizeof, float and double.  Clearly if the committee 
actually intended macro definitions of keywords to be valid when macros 
from standard headers are used they'd have allowed for it in such examples 
in the standard and the Rationale.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions can make compilation fail

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #5 from Ulrich Drepper <drepper.fsp at gmail dot com> 2010-10-22 17:07:35 UTC ---
There really is no problem.  If you redefine reserved words and then use any
part of the system, it's your own fault.  Just don't do it.  We have for
history reasons a work-around for const in the headers but I have no interest
to add more.  That's anything but productive.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions can make compilation fail

[vincent+libc at vinc17 dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

Vincent Lefèvre <vincent+libc at vinc17 dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WONTFIX                     |
     Ever Confirmed|1                           |0

--- Comment #6 from Vincent Lefèvre <vincent+libc at vinc17 dot org> 2010-10-22 19:03:31 UTC ---
(In reply to comment #4)
> There's an example of a possible definition for fpclassify in 7.12.3.1#4 
> that uses the keywords sizeof, float and double.

I noticed that, but I'd say that could be the example that is buggy (and in any
case, it is not normative).

> Clearly if the committee actually intended macro definitions of keywords to
> be valid when macros from standard headers are used they'd have allowed for
> it in such examples in the standard and the Rationale.

The committee's intent is not clear, as 7.1.2#4 says: "The program shall not
have any macros with names lexically identical to keywords currently defined
prior to the inclusion." If the intent was to disallow such macro definitions
completely, the standard would not have said "prior to the inclusion". The fact
that the committee said "prior to the inclusion" implies that they knew that
such macros could be defined after the inclusion and didn't want to disallow
them. Perhaps the committee didn't think about the consequences on macros,
though.

(In reply to comment #5)
> If you redefine reserved words and then use any part of the system, it's your
> own fault.

The point is that
1. keywords are not reserved until translation phases 7 and 8 (and the standard
documents when such keywords can't be used as macro names);
2. the user doesn't use the keyword in his code (the use of a keyword by a
standard macro is hidden).

If you disagree with the standard, then you should submit a defect report.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions can make compilation fail

[vincent+libc at vinc17 dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

--- Comment #7 from Vincent Lefèvre <vincent+libc at vinc17 dot org> 2010-10-22 22:22:23 UTC ---
(In reply to comment #6)
> 2. the user doesn't use the keyword in his code (the use of a keyword by a
> standard macro is hidden).

Just to give an example about this, a user may decide to define

#define float the_float_type_must_not_be_used

as a way to ensure that the float type is not used in the code, while still
allowing double for FP computations. But the fpclassify macro should still be
usable as it makes sense on double. And if the fpclassify uses the float
keyword, it breaks the code.

There might be other good reasons to define macros with the name of a keyword.
It would not be the first time one may think that some feature would/should not
be used, but it would become more meaningful in the future. Standards are there
to say whether something is allowed or forbidden.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions can make compilation fail

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12153

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #8 from Ulrich Drepper <drepper.fsp at gmail dot com> 2010-10-23 01:36:28 UTC ---
> If you disagree with the standard, then you should submit a defect report.

Hell no.  The macros are meant to be written like that.  This has always been
the case and developers of the standard know about _this_.  All you want is
making trouble for absolutely no valid and useful reason.  If you want any
change then talk people into explicitly declaring this type for assert etc
definitions invalid.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12153] use of keywords in macro definitions can make compilation fail

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12153

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.