>>> + 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 mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
