From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10302101428.AA12423@clio.rice.edu> Subject: Re: djgpp: djgpp/include/string.h,strings.h To: djgpp-workers AT delorie DOT com Date: Mon, 10 Feb 2003 08:28:19 -0600 (CST) In-Reply-To: <3E47A3BD.537F8D34@phekda.freeserve.co.uk> from "Richard Dawe" at Feb 10, 2003 01:06:05 PM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > ../../../../include/libc/fsexthlp.h:32: warning: inline declaration ignored > > for function with `...' (do we really need inline?) > > We could leave it to the compiler to inline it, as it sees fit. > has a bunch of inline functions, which are defined as inline > using "__inline__" rather than "inline", so perhaps should > use "__inline__" too. Could try it. It's just a warning, and only in compiling the library, so we could leave it. (You have to edit gcc.opt anyway since some of the new switches aren't supported by older GCC). > > ../../../../include/stdint.h:27: parse error before `__extension__' > > ../../../../include/stdint.h:37: parse error before `__extension__' > > "__extension__" is just a way of ignoring errors when -pedantic is used. And I looked at this for a few minutes - and it looks like a gcc 2.7.2.1 bug. It works with __extension__ in other contexts during compiling, but for some reason it just won't take this one. #defining it away makes it compile. > I don't know why we use "__extension__" in . gcc supports long long, > so we have to provide *int64_*t. See C99, section 7.18.1.1: "Exact-width > integer types", which is about *int_*t: > > "These types are optional. However, if an implementation provides integer > types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding > typedef names." > > I suppose gcc 2.7.2.2 may support 64-bit integers. It's been so long since I > used that version, that I can't remember. ;) If it does support 64-bit > integers, then we can remove "__extension__". It does support them, so it's just a matter of deciding what to do - but I'm busy this week. When I get a chance.