>> So, in summary, except for the null-pointer-constant special case, >> converting integers to pointers is intended to be useful in >> machine-dependent code, but is not portable beyond that. > ISO C99 specifies intptr_t and uintptr_t though,
Yes - but there is no promise that an intptr_t or uintptr_t obtained in any way other than casting a pointer-to-void to it will convert to anything useful. Also, it says that "[t]hese types are optional"; they do not have to exist. > and POSIX [...] has a notion of (PTR)-1 for long, I'm not sure whether "for long" here is "for a long time" or whether it has something to do with C's long type. Also, "has a notion of" is notably imprecise; what exactly does POSIX specify about them? > just "recently" (in Issue 6) gave (void*)-1 the symbolic MAP_FAILED > constant name. Ugh. Mandating what something like MAP_FAILED epxands to defeats much of the point of giving it a symbolic name. But I don't think that means it has to differ from (void *)0, or any other specific void * not obtained from mmap, though, does it? MAP_FAILED just has to differ from any possible valid mmap return, or at least that's what (little) I've read says. > It never hit me, i always used (register-sized-integer)/(pointer) > back and forth casting. And, I would hazard the guess, you have always been using mainstream hardware and OSes. As I said, >> On most current systems, no, it won't cause trouble; it will do >> pretty much what you presumably expect. And, if you don't care about portability beyond "most current systems", then, sure, go for it. But, as I also wrote, >> I would hope that lynx wants to be more portable than that, though. As for >> char magic_value; // maybe static, if not needed beyond file scope >> socks5_proxy = &magic_value; >>... >> if (socks5_proxy == &magic_value) ... > Really not!! If so then (char*)(intptr_t)-1! This is slightly less portable than (char *)-1 (slightly less because intptr_t is an optional type, and no more because (a) the intptr_t in question was not obtained by casting a void * and thus there are no promises about what it may convert to and (b) because you're casting it to char *, something about which no promsies are made anyway - the promises are about converting intptr_t to void *). I can't make you write portable code. Nor would I if I could. But, with a project like lynx that I care about, I do feel a duty to call out blatant nonportabilities as such. If lynx lets this sort of code in, I'll be disappointed in them, but that's about where it'll end. If I get bitten by a resulting portability lose, I'll deal with that when it happens, like any other portability lose. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
