Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.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: Mon, 30 Mar 2015 13:20:44 -0700 Organization: None to speak of Lines: 39 Message-ID: <87fv8mjkyr.fsf@kst-u.example.com> References: <52a5b8b7-8c35-4a96-a438-bf173a427e95@googlegroups.com> <20141223141323.231@kylheku.com> <1wnmw.309290$td6.28533@fx30.am4> <3db88ab4-eecb-468d-8cb1-c659bbac140d@googlegroups.com> <87y4mjlz53.fsf@kst-u.example.com> <55197925.1000002@verizon.net> <3cce398a-847a-4519-932b-49a51699ff40@googlegroups.com> <2ec960a8-1217-4ccd-bf9e-35c51ac5847f@googlegroups.com> <87k2xyjnr4.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="c77ff4d35e33d1c939d3461ebde8dd0d"; logging-data="11737"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+OovTsJQnanqHeSBRKM0ys" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:MGr+X/zVDnJHOO38sbspgXeRbWg= sha1:a6h7DLh2FJOITKhv/Np3nS+wBDM= Xref: csiph.com comp.lang.c:59308 Bartc writes: > On 30/03/2015 20:20, Keith Thompson wrote: >> Bartc writes: >>> This FILE* example makes clearer what problems can occur in relying on >>> const' to make data read-only. >> >> I wouldn't expect defining a FILE object as "const" to affect whether I >> can write to the external file. The FILE object is an object of a type >> named "FILE"; I know nothing more about it than that, since it's >> effectively an opaque type. (As of C11, it can even be an incomplete >> type.) The external file isn't even an object; writing to the file is >> not the same as modifying an object. >> >> If you declare >> >> const FILE *foo; >> >> it conflicts with the semantics of the functions declared in . >> So don't do that. (If you don't want to modify the external file, open >> it with a mode of "r" or "rb".) > > As I said, the const FILE* example was an illustration. In user > defined data, there could be similar problems in trying to protect > data with the crude mechanism provided by 'const', which can in fact > give a false sense of security. Not if you understand how "const" works. > There might be a pointer to a FILE-like descriptor which needs to be > written to even though the actual data (via further pointers or even > within the descriptor) should not be modified. Right. So what's the problem? -- 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"