Am Dienstag 27 Juli 2010, um 11:18:49 schrieb Ludovic Rousseau: > Comments from others?
I agree it is strange to have "DWORD" as 64 bit number. at least to my knowledge byte, word, double-word are fixed sized types with 8, 16, 32 bit. but if for whatever historical reasons pcsc-lite has "DWORD" in the header file and that ends up to be a 64 bit type on 64bit unix/linux/mac os X machines, so be it. no reason to break programs or change abi or anything like that. lots of programmers didn't think about 64bit until someone had already ported their app to 64bit architectures, and thus "will this be 32bit or 64bit?" was never decided for many values, but simple ended up one way or the other for historical reasons. maybe it was something like that for pcsc-lite too? no idea. so, what to do? if other operating systems changed the header files so they use a term different than "DWORD" that actually reflects the situation (32 bit unsigned int on 32bit, 64 bit unsigned int on 64bit), then such a change would be fine with me. i.e. don't change abi or break apps, but if there is a way the header file has type names that do the expected thing, then that would be nice. but maybe investing work here isn't worth the hassle. people have written apps using "DWORD" in their code to access pcsc-lite, so we would still need to define "DWORD" in pcsc-lite headers as 64bit data type, even if it confuses people. not doing so would break the compilation of such apps. you could write a new header file, or use a define inside the old ones, so people could switch from "DWORD" to some new name for the same type, some name that reflects the "64 bit on 64 bit systems" situation better. but who would migrate their app, why and when? in the end, not doing anything would be ok with me. maybe some documentation or big fat comments in the relevant headers, unless they already exist. Regards, Andreas _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
