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

[Mouse]

>>> +     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.

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

/~\ 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