From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16792 invoked by alias); 5 May 2005 23:29:28 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 16655 invoked from network); 5 May 2005 23:29:21 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 5 May 2005 23:29:21 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifix.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 03F16169E1; Thu, 5 May 2005 17:43:50 -0700 (PDT) Subject: Re: Another HP-UX IA64 Build patch From: James E Wilson To: DJ Delorie Cc: sje@cup.hp.com, binutils@sources.redhat.com In-Reply-To: <200505052224.j45MOH22019801@greed.delorie.com> References: <200505052024.NAA17735@hpsje.cup.hp.com> <200505052042.j45Kg1Po027434@greed.delorie.com> <1115329225.8413.146.camel@aretha.corp.specifixinc.com> <200505052224.j45MOH22019801@greed.delorie.com> Content-Type: text/plain Message-Id: <1115335760.8413.204.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Fri, 06 May 2005 01:57:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00220.txt.bz2 On Thu, 2005-05-05 at 15:24, DJ Delorie wrote: > One option is to not allow the use of basename() without the > HAVE_DECL_BASENAME test. We can do this by #definining basename() to > you_forgot_the_have_decl_basename_check() in the non-prototype case in > libiberty.h. This makes the solution more obvious, but does not seem to fix anything. The problem here is that libiberty.h declares basename always, even if you aren't using it. Thus we must always have a configure test for basename even if we aren't using it. This change just makes it more obvious that the otherwise unnecessary configure test is missing. Also, as you mention, this is likely to break lots of code using libiberty.h that isn't already using -Wstrict-prototypes and -Werror, as the current libiberty.h code fails only in this case. > But how does gcc deal with system headers that have empty prototypes > for functions? If we can hook into that, that would help. But I > wouldn't recommend using where "libiberty.h" is > appropriate. I think the main answer to this is that now we require an ISO C compiler, everybody has prototypes for everything that matters. -Wstrict-prototypes does not warn for declarations in system header files. -Wmissing-prototypes requires a prototype before use. So we only need to ensure that a prototype exists in the local gcc system.h (or whatever) if there is no prototype in the system header files. However, I don't think this is a problem, because I think everybody we care about has prototypes in the system header files nowadays. This fails in the libiberty.h case, because libiberty.h is not a system header file, and contains a non-prototype declaration for basename. Using would fix this, but as you say, might cause other problems, like getting the wrong version of it. The use of libiberty.h in gcc itself is not a problem, because gcc has the basename configure check. > basename is different because we *can't* just emit a prototype, as it > sometimes conflicts with the OS's prototype. The prototype is only emitted if there is a configure check for basename, and configure failed to find it. In this case, there should be no conflict unless the configure check is broken > It's the only one that doesn't return "int" so we must, or we corrupt > pointers on 64-bit-pointer machines. So what you are saying here is that we declare basename even if there is no configure check for basename, just in case someone needed the configure check but forgot to perform it. However, in this case, I would argue that the libiberty.h user is clearly broken (because of the missing configure check), and it isn't libiberty's responsibility to make it work. Changing this might break some programs that have relied on this feature though. This brings us back to the previously suggested solutions, hack in __hpux__ like is done for other targets, or add otherwise unnecessary basename configure checks in the binutils and gas directories. I suppose if we want a more involved fix, we could modify gcc to define some macros when -Wstrict-prototypes -Wmissing-prototypes and -Werror are used. We can then modify libiberty.h to check for these macros. If all three are defined, then we don't emit the non-prototype declaration of basename. In this case, if someone did use it by accident without the configure check, and it was necessary, then they would get an error from gcc for the missing prototype. This seems safe, but requires a new gcc release to build binutils, which is impractical. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com