On Tue, Jul 7, 2009 at 04:02, Martin Mares<mj@xxxxxx> wrote: >> > Even though it is probably OK to assume that <inttypes.h> exists whenever >> > <stdint.h> does, keeping using PCI_HAVE_STDINT_H for that is confusing :) >> >> Are you suggesting just removing the defined(PCI_HAVE_STDINT_H) part? > > I suggest either removing the test altogether (if we come to a conclusion > that we can rely on C99 includes everywhere), or renaming the symbol > to PCI_HAVE_INTTYPES_H. >From my research, inttypes.h and stdint.h has existed since the listed timeframe for each of the following systems. I looked for evidence in public source repositories and on mailing lists of folks trying to compile software. Linux GNU/kFreeBSD GNU Hurd -These 3 are dependant on GNU libc which has had the files since the late '90s. FreeBSD - since at least 5.x, which is long out of even legacy releases and was released in 2003. NetBSD - since 2001 or so at least OpenBSD - since at least 2003 AIX - at least since version 5.1, which was released in 2001 and end of lifed in 2006. 4.3.3, which didn't have the files, was EOLed in 2003. Windows - The best one can do is a third party implementation. CYGWIN - don't know Solaris (since Solaris 10 at least) - There is evidence that Solaris 8 or 9 may not have had inttypes.h, but I think it's just that you had to get the sun's compilers (or another c library) to get the header file. Having said all this, I suggest we remove the test altogether, which is what I have sitting in my take 7 version of the patch. I also suggest that we drop the non-C99 types (like u_int32_t), as I suspect that the uint32_t style types will probably work pretty far back considering the above observations. I think that we can safely say that we are covering at least 6 years worth of development environments (back to 2003), if not more. Here is my proposal, for that section in the types.h, I don't think that we need the test for C99. It should probably look more like the following: #ifndef PCI_HAVE_Uxx_TYPES #ifdef PCI_OS_WINDOWS #include <windef.h> typedef BYTE u8; typedef WORD u16; typedef DWORD u32; typedef unsigned __int64 u64; //define printf format strings for pci address for windows here #else #include <inttypes.h> typedef uint8_t u8; typedef uint16_t u16; typedef uint32_t u32; typedef uint64_t u64; //define printf format strings for everyone else here #endif #endif>·/* PCI_HAVE_Uxx_TYPES */ I think this will work on all the above systems since 2003 at least. >> Also, I looked at the configure script and it looks like >> PCI_HAVE_STDINT_H is only defined on sunos. That doesn't make much >> since to me. > > AFAIK old versions of Solaris had some C99 includes, but not a C99 compiler, > so the STDC_VERSION test did not trigger. What would you think about trying to remove that STDC_VERSION test given the above info? >> For non-MS Windows systems, what systems do we support that don't have >> those c99 headers? > > As I have already said, I am not sure about that as I have never seen > some of the supported systems myself. Current versions of all systems > except Windows should be safe, but older versions frequently lack them. Windows can be worked around. As for the other system, does the info above make you feel any more confident? >> I found that AIX 4.x, which has been end of lifed for a while, doesn't >> have the headers, but AIX 5.3 does. Do we really need to maintain >> support of systems as old as AIX 4.x? > > Judging from the occasional bug reports I receive, people still use such > systems, so as long as supporting the old systems is a matter of a couple of > lines, I would really like not to break them. > > I would therefore keep the fallback to u_intXX_t types, but instead of u_int64_t > (for which we do not know the format sequence) use either long or long long, > depending on ULONG_MAX. Would you be willing to remove the u_intXX_t style types given the above info? >> Also, do we have a list of supported platforms somewhere? > > They are listed in README, but only names of the platforms, not specific versions. Thanks for the pointer. That's where I got the list of platforms to check for which versions had inttypes.h and stdint.h. >> I don't understand this comment fully. Previously, these values were >> u32. Didn't they get printed the same way, that is using the non-u32 >> format strings? > > In exec_op(), we call: > > printf(formats[width]+1, x); > > (and similarly trace()). I.e., we are printing the same variable `x', but > with different format strings. As long as the format strings were "%<something>x", > it worked, because all those required `unsigned int' as an argument. If you > change `x' to u64, you have to change _all_ format strings used on it. I see. Thanks for the explanation. wt -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
