Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lawrence D'Oliveiro Newsgroups: comp.os.linux.advocacy Subject: Re: More Funny Stuff From C Date: Wed, 12 Jun 2024 02:43:07 -0000 (UTC) Organization: A noiseless patient Spider Lines: 20 Message-ID: References: <17d716103c089ab3$7951$675878$802601b3@news.usenetexpress.com> <2ej96j1mbvgiok4q5c57vdlo94itpfu5dt@4ax.com> <6664e989$0$2363151$882e4bbb@reader.netnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 12 Jun 2024 04:43:07 +0200 (CEST) Injection-Info: dont-email.me; posting-host="114c653c06754bac2979cba4b47e2f9e"; logging-data="1539567"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/OLKknnOH/rbDwGymVEoLu" User-Agent: Pan/0.158 (Avdiivka; ) Cancel-Lock: sha1:MfpXF/CMyF3cSi1X4psncaq6XC4= Bytes: 2424 On 11 Jun 2024 18:23:28 GMT, rbowman wrote: > ... I've hit instances using functions > in legacy code where one const in a function resulted in having to > spread const around to keep the compiler from whining. Dennis Ritchie himself pointed out some pitfalls with the “const” concept early on. For example, take this standard library routine: char *strstr(const char *haystack, const char *needle); Note that the result is a (non-const) pointer into one of the arguments. But the arguments are const! So the function is not typesafe. It was done this way so that, if the user passed a pointer into a modifiable string, they could get back a pointer they could use to make further modifications. The right solution would have been to create two versions of this routine, one with a non-const haystack pointer returning non-const, and another with a const haystack pointer, returning const.