On 02/07/12 12:03 am, Erik de Castro Lopo wrote:> Dave Yeo wrote: > >> This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been >> been replaced by klibc. Considering the age of EMX and lack of testing >> and that klibc contains so many improvements I think this is exceptable. > > Sorry Dave, I can't do that. Or rather sorry, the patch doesn't apply. > Probably a line wrapping issue. Maybe you should try send it as an > attachment. >Another try Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-even-more-CPP-hackery.patch Type: application/x-patch Size: 4731 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20120207/6e2d7707/attachment-0001.bin
On 2/8/2012 03:33, Dave Yeo wrote:> On 02/07/12 12:03 am, Erik de Castro Lopo wrote: >> Dave Yeo wrote: >> >>> This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been >>> been replaced by klibc. Considering the age of EMX and lack of testing >>> and that klibc contains so many improvements I think this is exceptable. >> >> Sorry Dave, I can't do that. Or rather sorry, the patch doesn't apply. >> Probably a line wrapping issue. Maybe you should try send it as an >> attachment. >> > > Another try > Dave > >Why is inttypes.h using OS ifdefs? Shouldn't it be HAVE_INTTYPES_H? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20120208/dc64b6bd/attachment.pgp
JonY wrote:> On 2/8/2012 03:33, Dave Yeo wrote: > > On 02/07/12 12:03 am, Erik de Castro Lopo wrote: > >> Dave Yeo wrote: > >> > >>> This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been > >>> been replaced by klibc. Considering the age of EMX and lack of testing > >>> and that klibc contains so many improvements I think this is exceptable. > >> > >> Sorry Dave, I can't do that. Or rather sorry, the patch doesn't apply. > >> Probably a line wrapping issue. Maybe you should try send it as an > >> attachment. > >> > > > > Another try > > Dave > > Why is inttypes.h using OS ifdefs? Shouldn't it be HAVE_INTTYPES_H?Agreed. Dave, I'll take your patch as it is and swicth to HAVE_INTTYPES_H where appropriate. CHeers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On 02/07/12 02:08 pm, JonY wrote:> On 2/8/2012 03:33, Dave Yeo wrote: >> On 02/07/12 12:03 am, Erik de Castro Lopo wrote: >>> Dave Yeo wrote: >>> >>>> This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been >>>> been replaced by klibc. Considering the age of EMX and lack of testing >>>> and that klibc contains so many improvements I think this is exceptable. >>> >>> Sorry Dave, I can't do that. Or rather sorry, the patch doesn't apply. >>> Probably a line wrapping issue. Maybe you should try send it as an >>> attachment. >>> >> >> Another try >> Dave >> >> > > Why is inttypes.h using OS ifdefs? Shouldn't it be HAVE_INTTYPES_H? >I didn't want to touch any Borland C related stuff without being able to test. Dave
Dave Yeo wrote:> Another tryActually there are still some issues with this patch, mainly around your changes to incluce/FLAC/ordinals.h. This file is a public header file and hence, your changes: diff --git a/include/FLAC/ordinals.h b/include/FLAC/ordinals.h index 80d055b..dc2dafc 100644 --- a/include/FLAC/ordinals.h +++ b/include/FLAC/ordinals.h @@ -32,10 +32,18 @@ #ifndef FLAC__ORDINALS_H #define FLAC__ORDINALS_H -#if !(defined(_MSC_VER) || defined(__BORLANDC__) || defined(__EMX__)) +#if HAVE_CONFIG_H +# include <config.h> +#endif + +#if !(defined(_MSC_VER) || defined(__BORLANDC__)) #include <inttypes.h> #endif +#if HAVE_STDINT_H +#include <stdint.h> +#endif + typedef signed char FLAC__int8; typedef unsigned char FLAC__uint8; rely on "config.h" which is only available when FLAC is compiled, not when this file is installed in /usr/include/FLAC or whereever. I'll accept the rest of the patch. For the problem of this file, I think the best solution is to just remove all the CPP hackery and assume that a C99 <stdint.h> is available. THis would then make it incumbent on any developer that includes (either directly or indirectly) include/FLAC/ordinals.h to include some version of <stdint.h> first, even if it is just a mininal one with typedefs for the minimal set of sized ints. Does that make sense? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/08/12 01:32 am, Erik de Castro Lopo wrote:> Dave Yeo wrote: > >> Another try > > Actually there are still some issues with this patch, mainly > around your changes to incluce/FLAC/ordinals.h. This file is a > public header file and hence, your changes:Sorry about that, forgot that it is a public header. [...]> rely on "config.h" which is only available when FLAC is compiled, > not when this file is installed in /usr/include/FLAC or whereever. > > I'll accept the rest of the patch. For the problem of this file, I > think the best solution is to just remove all the CPP hackery and > assume that a C99 <stdint.h> is available. THis would then make it > incumbent on any developer that includes (either directly or > indirectly) include/FLAC/ordinals.h to include some version of > <stdint.h> first, even if it is just a mininal one with typedefs > for the minimal set of sized ints. > > Does that make sense? >Yes that makes sense. Requiring a C99 compliant compiler seems quite reasonable. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (OS/2) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBTzNshnoc36Ns6m33AQKt5Af7BnGpopuXhyPJEYHc6NgYMMM8F6VzEtFa MREYy7gT0hw/2jGzQ2BV0bAJk3xvTUrgXt79l9/WDCbudkSLiarAZXHMGI8gi0nJ qfxEih7bzSO5SkTK+NRAtxFQFUXW+pqKigQZgjnw7zFCPO+gNCBR0Lx8OHEnn258 QmbGxTqxAboo1gRCmolJr2y2oa3be/fqMDKKysCOA6g+DFzQiCyBwjM/Pc+rI1bA mrQ7exyXv8yDTsXlQrOsYpG8plzMxb3DaiWys6ugXB0OAMEUt6ncZh88qO7ccYQ8 v7JsdmBPsadG2jKbIgJiRca9qLdKbHrfF33clfj7tADMdTdayle+lQ==02lV -----END PGP SIGNATURE-----