Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3E47A3BD.537F8D34@phekda.freeserve.co.uk> Date: Mon, 10 Feb 2003 13:06:05 +0000 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: djgpp: djgpp/include/string.h,strings.h References: <10302100511 DOT AA22688 AT clio DOT rice DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Charles Sandmann wrote: [snip] > It seems that at least gcc 2.8.1 builds current cvs libc OK. > > gcc 2.7.2.1 has some problems (does surprisingly well) > but this is expected with a 7 year old compiler. In particular, some > of the new headers cause errors. Thanks for testing this out. > e.g. > ../../../../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. > ../../../../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. 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__". Bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]