Mouse wrote in <202008080031.uaa13...@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) _______________________________________________ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev