Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
2020/08/07 20:03 ... Thorsten Glaser: Using (char *)-1 can cause traps on some platforms, or the compiler to replace the entire codepath (including backwards!) with nōnsense. And if the platform is x86, what of long and short pointers? Or do all the C-compilers use only the longest? If pointer value is -1, what does the compiler to make it longer when called for, and how does it know that it is? ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] the sun, the sun
2020/08/08 17:43 ... Steffen Nurpmeso: Being all in favour of keeping UTC aligned with the sun, whatever this means. I suspect that it is time to detach the physical second, that physicists use, from the second that is one 86400th of a day, and find a definition of "day" that depends on our experience of sunlight. The last definition that I found makes a day 86400 seconds. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Thorsten Glaser wrote in
:
|Steffen Nurpmeso dixit:
|
||>> socks5_proxy = _value;
|
|Just use that; the file already has a magic value
|you can use (hostname).
Whereas this is true, i still do not see the problem here really.
lynx uses (PTR)-1 itself, at least in src/tidy_tls.c, and it even
seems to have been written by Thomas Dickey himself!?!
Until absolutely necessary i will not exchange a builtin fixed
constant with some symbol that the linker must resolve
dynamically! I mean, for nothing???
|bye,
|//mirabilos
|--
|“It is inappropriate to require that a time represented as
| seconds since the Epoch precisely represent the number of
| seconds between the referenced time and the Epoch.”
| -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
I would really like to have CLOCK_TAI in the standard, getting rid
of leapsecond noise in calculations. ('Being all in favour of
keeping UTC aligned with the sun, whatever this means. However,
it seems we will not see leap seconds for a couple of more years,
if i read that right:
I believe there will be several years between the the last leap second
and the next, as there was between December 31, 1998 and December 31,
2005. The IERS publishes a long-term prediction of the average
rotation rate of the Earth, which they update in their Bulletin A each
week. The August 6, 2020, issue of Bulletin A contains this line:
UT1-UTC = -0.2147 - 0.00010 (MJD - 59075) - (UT2-UT1)
UT2 captures the seasonal change in the length of day, so it can be
ignored for long-term estimates. The important number, therefore, is
-0.00010, which I will call the UT1 slope.
The June 9, 2016, issue of Bulletin A contains this line:
UT1-UTC = -0.1734 - 0.00147 (MJD - 57556) - (UT2-UT1)
Which has UT1 slope equal to -0.00147. Since then the value of UT1
slope has increased steadily to its present value. It is larger now
than it has been at any time since January 6, 2005, which is the oldest
issue of Bulletin A that I have been able to locate. Based on the
current value of -0.00010 I estimate that the next leap second will be
on December 31, 2025, an interval of 9 years, which is longer than the
previous long interval of 7 years.
Hm.)
--End of
--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
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
[...(char *)-1...] > You know -- i for one do not care about the issue, Ah. Then, goodbye. If you don't even care about portability issues in lynx, there I have nothing more of value to contribute to this thread. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@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
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Steffen Nurpmeso dixit: |>> socks5_proxy = _value; Just use that; the file already has a magic value you can use (hostname). bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Mouse wrote in <202008081942.paa25...@stone.rodents-montreal.org>: |>> 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. You know -- i for one do not care about the issue, i have always done that, as below. The point for me was lynx tests for and uses intptr_t, and provides a "long" fallback i'd say (from git grep output, i have no idea of autotools). |> 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. They converted the "magic" use of (void*)-1 to a specific MAP_FAILED. |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. No, they got away from (void*)-1 to MAP_FAILED. |> 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, Yes, that is true. Two's-complement, sizeof(void*)=="sizeof(size_t)" only. |>> 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 = _value; |>>... |>> if (socks5_proxy == _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. That is utter rubbish, Mouse. --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
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
>> 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 = _value; >>... >> if (socks5_proxy == _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 HTMLmo...@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
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
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. | Exceptaspreviouslyspecified, 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 = _value; |... | if (socks5_proxy == _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
Re: [Lynx-dev] Adding $SOCKS5_PROXY support, changing command line option
Hello. Thorsten Glaser wrote in : |Steffen Nurpmeso dixit: | |>Really?? This i do not understand. | |You’re only allowed to take pointers to actual objects. |It should probably be possible to use NULL somewhere, |but you can use as magic pointer. | |Using (char *)-1 can cause traps on some platforms, or |the compiler to replace the entire codepath (including |backwards!) with nōnsense. Well, hm, but not on POSIX compatible platforms for sure. MAP_FAILED for example is now explicitly defined (since Issue 6) where (void*)-1 was formerly used (also by the standard). There is also (iconv_t)-1 standardized, where iconv_t is usually a pointer. So this ISO C, then. Hm. But ok, i can use intptr_t, it is already used in the lynx code. Thanks for pointing this out. | |bye, |//mirabilos |-- |In traditional syntax ' is ignored, but in c99 everything between two ' is |handled as character constant. Therefore you cannot use ' in a preproces- |sing file in c99 mode.-- Ragge He unfortunately seems to leave. For weeks the server was totally gone, now at least the name resolves, but i cannot access it nonetheless. I really like pcc. |No faith left in ISO C99, undefined behaviour, etc. --End of Ciao, and a nice Sunday! --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
