package qmmp reassign 505047 libmodplug-dev thanks Zed Pobre wrote: > On Tue, Nov 11, 2008 at 04:17:37PM +0200, Eugene V. Lyubimkin wrote: >> typedef int8_t CHAR; >> typedef uint8_t UCHAR; >> typedef uint8_t* PUCHAR; >> typedef uint16_t USHORT; >> typedef uint32_t ULONG; >> typedef uint32_t UINT; >> typedef uint32_t DWORD; >> typedef int32_t LONG; >> typedef int64_t LONGLONG; >> typedef int32_t* LPLONG; >> typedef uint32_t* LPDWORD; >> typedef uint16_t WORD; >> typedef uint8_t BYTE; >> typedef uint8_t* LPBYTE; >> typedef bool BOOL; >> typedef char* LPSTR; >> typedef void* LPVOID; >> typedef uint16_t* LPWORD; >> typedef const char* LPCSTR; >> typedef void* PVOID; >> typedef void VOID; >> ->8- >> >> are not under #ifdef and located in stdafx.h, so they rely on stdint.h >> unconditionally and, therefore, header should include it unconditionally. > > Er, no, the point of having an ifdef at all is that they *don't* rely > on stdint.h unconditionally -- they can be provided either by > inttypes.h (most commonly seen on HP-UX and AIX, IIRC) or by stdint.h, > so what this code is doing is allowing a system that has the defines > in one and completely misses the other to still compile the code. > They're only unconditionally provided by stdint.h *on Debian systems*. > While it's technically feasible for me to force it in a > Debian-specific patch, this will cause other code depending on > libmodplug to behave this way to break as soon as it is placed into a > typed-via-inttypes environment. > > If anything, the bug in modplug is that it doesn't have *enough* > ifdefs, because there's actually a *third* place that these defines > can be found: sys/types.h. Unless someone with an Interix system > actually complains, however, I'm going to ignore that. Ok, then libmodplug should do "#if defined(<one>) #elif defined(<two>) #else #error intXYZ_t types are unavailable #endif" rather than generate errors in applications linked to libmodplug. This is a correct approach, and approach which I currently see in libmodplug's stdafx.h is wrong and needs fixing. You can't rely on intXYZ_t types without checking that at least one of <inttypes.h> or <stdint.h> headers are included (see above example of check).
> In any case, the technically correct solution is for all packages > making use of known-size defines, even indirectly, to test for the > source of those defines and include as appropriate. [snip] Then why stdafx.h header define such types? Header it_defs.h use BYTE, WORD rather than int8_t (or unsigned char) and int16_t, why? (well, no problem, use it, but make headers correct (again, see above :))). >> P.S. IMHO, it would be good if these Windows-related defines went to >> /dev/null in future. > > Windows-related? I think you misunderstand either the scope of the > problem, or the entire purpose of the defines. This is unrelated to this bug and thus off-topic on this bug thread, but I can say that 'LPVOID' and company are Windows API crap under Linux code base of libmodplug and I don't see a reason why a Linux code should even see such types. But it's my own IMHO and wish. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com Ukrainian C++ Developer, Debian APT contributor
signature.asc
Description: OpenPGP digital signature
