Mouse wrote in <202008081942.paa25...@stone.rodents-montreal.org>: |>> 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.
You know -- i for one do not care about the issue, i have always done that, as below. The point for me was lynx tests for and uses intptr_t, and provides a "long" fallback i'd say (from git grep output, i have no idea of autotools). |> 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. They converted the "magic" use of (void*)-1 to a specific MAP_FAILED. |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. No, they got away from (void*)-1 to MAP_FAILED. |> 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, Yes, that is true. Two's-complement, sizeof(void*)=="sizeof(size_t)" only. |>> 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. That is utter rubbish, Mouse. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev