Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option

[Steffen Nurpmeso]

Mouse wrote in
 <202008081942.PAA25455@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)