Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Difference between these pointer syntaxes Date: Thu, 18 Aug 2016 13:04:41 -0700 Organization: None to speak of Lines: 61 Message-ID: References: <4991b886-1f54-4098-bf57-ba59710b99d1@googlegroups.com> <87bn0rut34.fsf@bsb.me.uk> <9283b112-8250-4e0b-b149-6ca728a3200b@googlegroups.com> <07faa95e-2470-4375-93e9-15e79ee4e0e4@googlegroups.com> <55578778-4482-458e-b43d-b763732c0054@googlegroups.com> <87mvkas5gb.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="26067"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1G06MrmohHLeSx3ZBEmoO" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:JHiZYk3XRd9u+cdW90jyFnpDyGk= sha1:e0Z8Ru6qWlTfrjW7v9Y7Q+tPFcc= Xref: csiph.com comp.lang.c:92477 supercat@casperkitty.com writes: > On Thursday, August 18, 2016 at 11:03:01 AM UTC-5, Keith Thompson wrote: >> In my opinion, the ANSI C committee made a mistake here. It *could* >> have been done nicely in C -- by having introducing two different >> versions of the strchr function (perhaps strchr and strcchr). Several >> other standard library functions have the same problem. > > What makes you think the problem doesn't exist in user code, in ways that > can't be solved via code duplication (e.g. because one needs to have > collection of pointers to things, some of which are const and some of > which aren't, and needs to be able to write the non-const ones)? There > needs to be a type for "pointer to a possibly-const thing that might be > used (after casting) to write the thing if it wasn't const". I.e. the > kind of "const" that C has. What makes you think I don't think such problems exist? Plenty of problems exist in user code. The `const` keyword clearly does not solve all possible problems with objects that should or should not be writable. It might be nice to have an array object some of whose members are read-only and some of which are writable, with the compiler enforcing it. Many such things can be addressed using wrappers and opaque data types -- or just programmer discipline, with or without the compiler's help. My only point is that strchr() pokes a hole in const-safety, letting you attempt to modify a const-qualified object with no warning from the compiler. A simple example: #include #include int main(void) { const char *s = "hello"; char *ptr = strchr(s, 'h'); *ptr = 'H'; puts(s); } (With gcc, this dies with a segmentation fault. With tcc it prints "Hello".) And in my opinion it would have been better to plug that hole by splitting strchr() into two functions, something like: char *strchr ( char *s, int c); const char *strcchr(const char *s, int c); I make no claims that such a change would have solved all problems having to do with read-only data, merely that in my opinion it would have been an improvement over the current situation. On the other hand, given the current definition of strchr(), programmers merely have to exercise some case to avoid accidentally modifying read-only objects (with insufficient help from the compiler), so it's not *that* bad. -- 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"