From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22707 invoked by alias); 28 Jun 2008 01:00:00 -0000 Received: (qmail 22699 invoked by uid 22791); 28 Jun 2008 00:59:59 -0000 X-Spam-Check-By: sourceware.org Received: from mo-p07-ob.rzone.de (HELO mo-p07-ob.rzone.de) (81.169.146.190) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 28 Jun 2008 00:59:34 +0000 X-RZG-CLASS-ID: mo07 X-RZG-AUTH: :Ln4Re0/tc/4+RPs3/JP8/Hc3Cqxuq9k84i0ZqlPB1Qu/qFORHSYrImwqMBg= Received: from linuix.haible.de ([81.210.233.62]) by post.webmailer.de (fruni mo54) (RZmta 16.45) with ESMTP id N06a1ck5RMMSXJ ; Sat, 28 Jun 2008 02:59:31 +0200 (MEST) (envelope-from: ) From: Bruno Haible To: Daniel Jacobowitz , Joel Brobecker Subject: Re: [RFC] Use gnulib's stdint.h. Date: Sat, 28 Jun 2008 07:10:00 -0000 User-Agent: KMail/1.5.4 Cc: bug-gnulib@gnu.org, gdb-patches@sourceware.org References: <20080605184041.GA25085@caradoc.them.org> <20080627185907.GA11664@adacore.com> <20080627191314.GA19538@caradoc.them.org> In-Reply-To: <20080627191314.GA19538@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806280259.26427.bruno@clisp.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00527.txt.bz2 Hi, For some context, the message you were replying to is . Generally the experience we've made with gnulib is: * It's wise to include the system headers first, and the application headers after that. This minimizes the risk that #defines in the application headers make the system headers malfunction. (Examples: '#define unused' on Windows, '#define PC' on SVR4 systems, many more ...) * Never assume that a particular header has not been included. Assuming that, say, functions are not declared is 1. a portability problem, because may need to include , or similar, 2. a maintainability problem, because when you want to use, say, perror() in such a file, you are at a dead end. Daniel Jacobowitz wrote: > Joel Brobecker wrote: > > There are two distinct issues that I have seen so far: > > > > 1. dfp.c includes libdecnumber/dpd/decimal128.h which ends up > > including gstdint.h. But before we included decimal128.h, we > > had already included defs.h which includes gnulib/stdint.h. > > The two files end up colliding. > > > > For instance, gstdint.h contains: > > typedef int16_t int_least16_t; > > > > But gnulib/stdint.h also contains: > > #define int16_t short int > > #define int_least16_t int16_t > > > > So we end up with the above being rewritten to: > > typedef short int short int; > And if we change libdecnumber to use gnulib's version we'll > undoubtedly break gcc. libdecnumber's gstdint.h appears to be generated by the autoconf macro GCC_HEADER_STDINT - obviously in the hand of the GCC maintainers. There are basically two ways out: a) Make gstdint.h use the types from if they are present. Change typedef int16_t int_least16_t; to #if !(defined INT_LEAST16_MIN && defined INT_LEAST16_MAX) typedef int16_t int_least16_t; #endif b) Make gstdint.h override the types from if they are present. Change typedef int16_t int_least16_t; to #undef int_least16_t #define int_least16_t gcc_int_least16_t typedef int16_t int_least16_t; The first approach is likely to need some additional tweaks for various platforms, whereas the second approach will work out-of-the-box. But if the APIs of libdecnumber use the int_least16_t etc. types, the first approach is better because it does not create two (possibly different) types for the same thing. > > 2. ctype/safe-ctype conflict. For instance, cp-support.c includes > > safe-ctype.h. But at the same time, we previously included > > defs.h, which itself includes gnulib/stdint.h, which includes > > which includes . > > > Problem #2 is a lot more problematic, however. I might argue that > > this is a actually bug inside gnulib and that gnulib/stdint.h > > should be generated in a way that avoids including other standard > > header files. No. gnulib makes no guarantee that particular headers or symbols are not defined. For three reasons: 1. We cannot control the #includes inside system headers. 2. gnulib turns on _GNU_SOURCE on glibc systems and __EXTENSIONS__ on Solaris. 3. In those places where gnulib could control these extra #includes, the price would be sets of #ifdefs that would be too clumsy to be maintainable. The bug is in safe-ctype.h: #ifdef isalpha #error "safe-ctype.h and ctype.h may not be used simultaneously" #endif Actually I don't see the reason for this #error: safe-ctype.h defines only uppercase-named macros, and defines only lowercase-named or underscore-prefixed macros. > > ... help avoiding the include. Ideally, gnulib would take > > care of that and avoid the include No, gnulib will not make not-include guarantees. See above. Bruno