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

[Mouse]

>> 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                mouse@rodents-montreal.org
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B