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

[Steffen Nurpmeso]

Mouse wrote in
 <202008080031.UAA13299@Stone.Rodents-Montreal.ORG>:
 |>>> +     socks5_proxy =3D (char*)-1;
 |>> Don=E2=80=99t do that, that is not portable.
 |> Really??  This i do not understand.
 |
 |Casting an integer, other than a compile-time constant expression with
 |value 0, to a pointer?  That is never portable.  (char *)-1 could do
 |anything from trapping immediately to producing a nil pointer to
 |producing a pointer that happens to match something else in live use
 |to, well, pretty much anything.  C99 says (6.3.2.3)
 |
 |       [#5] An integer  may  be  converted  to  any  pointer  type.
 |       Except    as    previously    specified,   the   result   is
 |       implementation-defined,  might  not  be  correctly  aligned,
 |       might  not  point  to  an entity of the referenced type, and
 |       might be a trap representation.56)
 |
 |The "previously specified" text covers, in [#3], the "integer constant
 |expression with value 0" case I mentioned above, in which case the
 |conversion is required to yield a nil pointer (C99 calls this a null
 |pointer; I don't like that name because of the confusion surrounding
 |NULL - see http://ftp.rodents-montreal.org/mouse/blah/2009-10-09-1.html
 |for my thoughts on that).  ([#1], [#2], and [#4] cover conversions
 |between various pointer types, not relevant to converting integers to
 |pointers.)
 |
 |"[I]mplementation-defined" means, among other things, that the next
 |implementation over may do something completely different from whatever
 |it is you expect.
 |
 |Footnote 56 says
 |
 |       56)The mapping functions for  converting  a  pointer  to  an
 |          integer  or  an  integer  to a pointer are intended to be
 |          consistent with the addressing structure of the execution
 |          environment.
 |
 |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, and POSIX has
a notion of (PTR)-1 for long, just "recently" (in Issue 6) gave
(void*)-1 the symbolic MAP_FAILED constant name.
It never hit me, i always used (register-sized-integer)/(pointer)
back and forth casting.

 |On most current systems, no, it won't cause trouble; it will do pretty
 |much what you presumably expect.  (While I didn't see enough context to
 |really know what you expect, most such suggestions come from a mindset
 |that I can perhaps summarize as "I thought every computer worked the
 |way mine does", which these days usually means either Windows or Linux
 |running on x86 or x64.)  In code that's not intended to be portable
 |beyond "most current systems", it may be fine.  I would hope that lynx
 |wants to be more portable than that, though.
 |
 |If you want a distinguished char * pointer that is not nil, the simple
 |_portable_ thing to do is to allocate a char and point to it:
 |
 |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!

--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)