| Deutsch English Français Italiano |
|
<86plqd7o4v.fsf@linuxsc.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!3.eu.feeder.erje.net!feeder.erje.net!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch <tr.17687@z991.linuxsc.com> Newsgroups: comp.lang.c Subject: Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Date: Mon, 12 Aug 2024 08:32:32 -0700 Organization: A noiseless patient Spider Lines: 47 Message-ID: <86plqd7o4v.fsf@linuxsc.com> References: <IoGcndcJ1Zm83zb7nZ2dnZfqnPWdnZ2d@brightview.co.uk> <20240801174026.00002cda@yahoo.com> <v8gi7i$29iu1$1@dont-email.me> <slrnvaorkl.34j6.candycanearter07@candydeb.host.invalid> <87zfpvfdk4.fsf@nosuchdomain.example.com> <v8ii17$2q5p1$1@dont-email.me> <87v80ig4vt.fsf@nosuchdomain.example.com> <82cc9501de86336cdef9fe610bce8e75238fb679@i2pn2.org> <v8ja83$2us0r$2@dont-email.me> <c1578de631eaf76975429819e7939acdf1c46897@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 12 Aug 2024 17:32:32 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f42e4005105099d89c60a754521770ce"; logging-data="3530086"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19spbn7VzZK8FJ+FQA3mxbaTF4Tz7G0eq8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:tbFA0m0s6hwMCn5zi47CFpusIQE= sha1:sWCIlr6gRnptmy4BENyE2cwL1ZI= Bytes: 3170 Richard Damon <richard@damon-family.org> writes: > On 8/2/24 2:58 PM, James Kuyper wrote: > >> On 8/2/24 14:42, Richard Damon wrote: >> >>> On 8/2/24 2:24 PM, Keith Thompson wrote: >>> >>>> Richard Harnden <richard.nospam@gmail.invalid> writes: >>>> [...] >>>> >>>>> Is there any reason not to always write ... >>>>> >>>>> static const char *s = "hello, world"; >>>>> >>>>> ... ? >> >> ... >> >>>> There's no good reason not to use "const". (If string literal objects >>>> were const, you'd have to use "const" here.) >> >> ... >> >>> The one good reason to not make it const is that if you are passing it >>> to functions that take (non-const) char* parameters that don't >>> actually change that parameters contents. >> >> Actually, that's not a good reason. If you can't modify the function's >> interface, you should use a (char*) cast, which will serve to remind >> future programmers that this is a dangerous function call. You shouldn't >> make the pointer's own type "char *". > > Depends on the library and how many times it is used. It may be a > perfectly safe call, as the function is defined not to change its > parameter, but being external code the signature might not be fixable. Right. It isn't always feasible to assume source code can be modified, especially without causing downstream problems. > Adding the cast at each call, may cause a "crying wolf" response that > trains people to just add the cast where it seems to be needed (even > if not warrented). Exactly. The last thing we want to do is have developers learn habits that tend to push code in the direction of being less safe.