Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: arranging items in a array with a sorted pointer-list Date: Fri, 04 Dec 2020 00:17:16 -0800 Organization: A noiseless patient Spider Lines: 100 Message-ID: <86im9im1df.fsf@linuxsc.com> References: <87wny3yp2n.fsf@bsb.me.uk> <20201130124004.239@kylheku.com> <%6dxH.49582$kM7.20584@fx43.iad> <20201130142116.891@kylheku.com> <1by2ii72fj.fsf@pfeifferfamily.net> <20201130174257.91@kylheku.com> <86y2ihoijs.fsf@linuxsc.com> <20201201081946.308@kylheku.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="bd193eaa76d2cf756f76f8149091c42d"; logging-data="11105"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/rcMek3FyLhQq8839/5Nb1wpqIIN7Bxf4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:5PvzRG0uvw4iHQfZKOROfbTG4YI= sha1:bhJd6IdVxma6RxbO4RS2K3b3dac= Xref: csiph.com comp.lang.c:156909 Kaz Kylheku <563-365-8930@kylheku.com> writes: > On 2020-12-01, Tim Rentsch wrote: > >> Kaz Kylheku <563-365-8930@kylheku.com> writes: >> >>> On 2020-12-01, Joe Pfeiffer wrote: >>> >>>> Kaz Kylheku <563-365-8930@kylheku.com> writes: >>>> >>>>> It can be the case that at the time the cast is written, there is no >>>>> const qualifier being cast away. The accident occurs when someone >>>>> later introduces const, and that cast now silently subverts it. >>>> >>>> Raising a question -- what would have been the downside (note that I'm >>>> recognizing it's Too Late, just Monday morning quarterbacking), when >>>> const was added to the language, to defining the cast so it doesn't >>>> throw the const away? >>>> >>>> ie if you had a >>>> >>>> const int x; >>>> >>>> and cast it with >>>> (char) x >>>> >>>> having x then treated as type >>>> >>>> const char >>>> >>>> My immediate intuition is that there is no case in which one would want >>>> to throw a const away with a cast, and this would have been a better >>>> choice. >>>> >>>> Thoughts? >>> >>> I think that it would be a good choice for C++ or a C dialect >>> inspired by C++, in which there are overloaded functions and other >>> features. >>> >>> jhere is the problem that the current function >>> >>> char *strchr(const char *str, int ch); >>> >>> could not be written in that dialect. [...] >> >> Think again. Yes it could. > > I don't see how it could be written in strictly-conforming code, as > it can be now, without doing anything where the requirements are not > defined, or at least unspecified or implementation-defined. (In English usage, there is no hyphen between the adverb "strictly" and the adjective "conforming".) > I'm excluding possibilities such as: > > char *strchr(const char *str, int ch) > { > union { char *y; const char *x; } u; > > u.x = str; > return strchr_impl(u.y, ch); > } There is no reason to exclude it. The behavior is well defined, and it produces the right result without having to depend on behavior that is unspecified or implementation defined. > I've thought about the memcpy hole: > > char *strchr(const char *str, int ch) > { > char *uqstr; > > memcpy(&uqstr, &str, sizeof uqstr); > return strchr_impl(uqsr, ch); > } > > In the memcpy call, the address of str is const char **, and that > converts to the required const void *. But does it? Arguably, that > conversion should arguably be banned under this dialect. Reason being: > it should be stipulated that pointer conversions must preserve const at > the same level of indirection. It can't just be that if the destination > type has a const in it somewhere in he type tree, it's okay. > > I'm thinking in the context that goal of this dialect is to make it > impossible to obtain a non-const-qualified pointer to any part of an > object, given a const-qualified pointer to it, without doing anything > erroneous or non-portable, where the requirements are not fastidiously > well-defined. > > In that spirit, a conversion sequence like const char * -> intptr_t > would also not be allowed in this dialect, because the const qualifier > on the pointer must be preserved, and has nowhere to land in the target > type, which has no matching indirection level. I see. I had thought you wanted to make a comment about C except with a different rule for casting. I see now that it was just a lead-in to an exciting game of Calvinball.