Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: my solution for Pascal strings Date: Tue, 24 Mar 2015 12:42:24 -0700 Organization: None to speak of Lines: 99 Message-ID: <87a8z2rxlr.fsf@kst-u.example.com> References: <52a5b8b7-8c35-4a96-a438-bf173a427e95@googlegroups.com> <9OVlw.186008$812.147958@fx20.am4> <0cd4a139-c466-4c04-95cc-f4436be0034c@googlegroups.com> <011mw.191541$812.115671@fx20.am4> <2a3a2358-7726-4c79-9e46-3bfd565253bc@googlegroups.com> <20141223141323.231@kylheku.com> <1wnmw.309290$td6.28533@fx30.am4> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="c77ff4d35e33d1c939d3461ebde8dd0d"; logging-data="8853"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Vx4W52NAd5z/8ZaPk8SAd" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:AXSMr4qYPmNRbEX2h3A9xHcmNGw= sha1:XWW0e+NB0WG3Obg9Z3+CRujhRpI= Xref: csiph.com comp.lang.c:58870 Tim Rentsch writes: > Malcolm McLean writes: >> On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote: >>> OK, we're obviously never going to agree. My main concern is >>> avoiding a proliferation of 'const' everywhere that will >>> introduce clutter and obscure the clarity of the code. >> >> [discussing some of the implications of using const] >> >> So Denis Ritchie opposed the introduction of const. [snip] > > You're wrong about that. During the ANSI standardization process, > Dennis Ritchie objected to one particular aspect of rules related to > 'const' types. But the implication in question was simply an > inadvertent error (as he himself remarked, "In discussion with > various X3J11 members, I learned that this section is now regarded > as an inadvertant error, and no one thinks that it will last in its > current form"), and indeed the passage in question did not make it > into the Standard. In http://www.lysator.liu.se/c/dmr-on-noalias.html, a copy of an article posted here on comp.lang.c on 1988-03-20, Dennis Ritchie discussed both const and noalias (the latter was dropped): By way of introduction, the important thing about `const' is that the current wording says, in section 3.3.4, that a pointer to a const-qualified object may be cast to a pointer to the plain object, but "If an attempt is made to modify the pointed-to object by means of the converted pointer, the behavior is undefined." Because function prototypes tend to convert your pointers to const-qualified pointers, difficulties arise. In discussion with various X3J11 members, I learned that this section is now regarded as an inadvertant error, and no one thinks that it will last in its current form. Nevertheless, it seemed wisest to keep my comments in their original strong form. The intentions of the committee are irrelevant; only their document matters. [...] One of the simplest routines, char *strchr(const noalias char *s, int c); can return its first parameter. This first parameter must be declared with `const noalias;' otherwise, it would be illegal (by the constraints on assignment, 3.3.16.1) to pass the address of a const or noalias object. That is, the type qualifiers in the prototype are not merely an optional pleasantry of the interface; they are required, if one is to pass some kinds of data to this or most other library routines. Unfortunately, there is no way in X3J11's language for strchr to return the value it promises to, because of the semantics of return (3.6.6.4) and casts (3.3.4). Whether the stripping of the const and noalias qualifiers is done by cast inside strchr, or implicitly by its return statement, strchr returns a pointer that (because of `const') cannot be stored through, and (because of `noalias') cannot even be dereferenced; by the rules, it is useless. (Incidentally, I think this observation was made by Tom Plum several years ago; it's disconcerting that the inconsistency remains.) This was a complaint about an interaction between "const" and "noalias". But there's *still* a serious problem with the strchr() and strrchr() functions. It's not an inherent probelm with "const", just with the way it's used in the standard library. #include #include int main(void) { const char s[] = "hello"; char *ptr = strchr(s, 'h'); *ptr = 'H'; puts(s); } Since strchr takes a `const char*` argument and returns a (non-const) `char*` result, it can return a non-const pointer to a const char object. The above program prints "Hello" on my system, violating the "const" on the declaration of s. No diagostic is required (and, FWIW, gcc doesn't warn). C++ fixes this by providing two overloaded version of strchr(): const char* strchr(const char* s, int c); char* strchr( char* s, int c); ANSI C probably should have done something similar, but giving them distinct names, perhaps strchr() and strcchr() (and likewise strrchr() and strrcchr()). -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"