On Feb 18, 2011, at 14:28, Pierre Joye wrote: > On Fri, Feb 18, 2011 at 2:17 PM, Dieter Baron > <dillo%danbala.tuwien.ac.at@localhost> wrote: >> On Feb 18, 2011, at 12:58, Pierre Joye wrote: > >> please use our time on more important issues. > > Sorry to waste my time testing your code, giving feedback, sometimes > bug fixes and as a side task, trying to make this project move > forward. Your feedback is very much appreciated, sorry if my mail came across otherwise. However, we had this discussion less than two months ago, and I was annoyed by it then. But since this is obviously a matter of concern for some of you, let's discuss it in further detail and settle it once and for all. I have a technical reason to do it this way, which I somehow don't seem to be able to get across: uint64_t et. al. are defined by the C99 standard; they are reserved types. If libzip defined them, and another library defined them as well, the application including both header files would get a compile error: redefinition of typedef uint64_t (yes, this happens even if the two typedefs are exactly the same, I just tested it with gcc 4.2.1). zip_uint64_t is an attempt to provide a portable, fixed width type. Applications can use it interchangably with other types of the same width/signedness, without explicit conversion. So if your application has access to fixed witdh types (provided by the compilation environment or defined by the application itself), it need not use zip_uint64_t in its code; it can use libzip as if the functions were defined using uint64_t. So what is your problem with these types, besides that they don't look nice (which is the price you often pay for portability, and which need not spread beyond libzip's code and header file)? yours, dillo
Made by MHonArc.