From owner-freebsd-hackers Wed Nov 29 21:26:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA24864 for hackers-outgoing; Wed, 29 Nov 1995 21:26:17 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA24823 ; Wed, 29 Nov 1995 21:25:57 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA28894; Thu, 30 Nov 1995 16:21:10 +1100 Date: Thu, 30 Nov 1995 16:21:10 +1100 From: Bruce Evans Message-Id: <199511300521.QAA28894@godzilla.zeta.org.au> To: freebsd-bugs@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org, ponds!rivers@dg-rtp.dg.com, rivers@dg-rtp.dg.com Subject: Re: Strangeness in /usr/include/runetype.h? Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >I've found an interesting situation, try compiling the following >file with -D_POSIX_SOURCE defined: >------------ start ------------- >#include >#include >#include >------------ end ------------- >You'll get: >In file included from /usr/include/ctype.h:51, > from t.c:4: >/usr/include/runetype.h:58: parse error before `rune_t' >/usr/include/runetype.h:58: warning: no semicolon at end of struct or union >/usr/include/runetype.h:59: warning: data definition has no type or storage class >... > my suggestion is that this becomes: >#ifdef _BSD_WCHAR_T_ >typedef _BSD_WCHAR_T_ rune_t; >typedef _BSD_WCHAR_T_ wchar_t; >#undef _BSD_WCHAR_T_ >#else >typedef _BSD_RUNE_T_ rune_t; >#endif This will result in rune_t sometimes being redefined. Typedefs can't be redefined. and should have something like #ifdef _BSD_WCHAR_T_ typedef _BSD_WCHAR_T_ wchar_t; #undef _BSD_WCHAR_T_ #endif and they should not pollute the namespace by defining rune_t. should have something like #ifdef _BSD_WCHAR_T_ typedef _BSD_WCHAR_T_ wchar_t; #undef _BSD_WCHAR_T_ #endif typedef _BSD_RUNE_T_ rune_t; should not pollute the namespace by including ... Bruce