Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: my solution for Pascal strings
Date: Fri, 27 Mar 2015 16:39:02 -0700
Organization: None to speak of
Lines: 56
Message-ID: <87bnjem2nd.fsf@kst-u.example.com>
References: <52a5b8b7-8c35-4a96-a438-bf173a427e95@googlegroups.com> <0cd4a139-c466-4c04-95cc-f4436be0034c@googlegroups.com> <Pt_lw.243014$v42.51757@fx19.am4> <011mw.191541$812.115671@fx20.am4> <2a3a2358-7726-4c79-9e46-3bfd565253bc@googlegroups.com> <cfrqnjFim7bU8@mid.individual.net> <VD3mw.244924$v42.74562@fx19.am4> <cfrvifFim7bU10@mid.individual.net> <OGbmw.146505$AC.64105@fx29.am4> <20141223141323.231@kylheku.com> <1wnmw.309290$td6.28533@fx30.am4> <cfuionFim7bU15@mid.individual.net> <Nixmw.139727$0o3.126620@fx45.am4> <b315520b-d339-4bf8-89cd-b2e4f5e298ed@googlegroups.com> <kfniodqid6h.fsf@x-alumni2.alumni.caltech.edu> <3db88ab4-eecb-468d-8cb1-c659bbac140d@googlegroups.com> <mevo3j$o77$1@dont-email.me> <e7ba96ae-9d01-47c1-8df0-ced45600b579@googlegroups.com> <06830a79-a412-4962-9a9d-82d67ef92011@googlegroups.com> <mf2mbc$66m$2@dont-email.me> <63fe1d33-5bdf-44bc-9d96-1a00712270e2@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="c77ff4d35e33d1c939d3461ebde8dd0d"; logging-data="8135"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uDBsNU+LIVfqly3azenWC"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:/KV8FEJAQYTRknP0mv5LBcNyaYw= sha1:cCO/01jz//eLVmU/THqrywoXNp8=
Xref: csiph.com comp.lang.c:59108

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, March 27, 2015 at 4:30:36 AM UTC, Les Cargill wrote:
>> Malcolm McLean wrote:
>> >
>> > 3) internals of an opaque structure are no business of
>> > caller. const breaks that paradigm.
>> 
>> 
>> Declaring a parameter const is a contract not to change a parameter. So 
>> it's an interface ... thing, not about the internals.
>> 
> Say we've got this.
>
> typedef struct
> {
>    PORT *intefacetoio;
>    long currentposition;
> } FILE;
>
> long ftell(FILE *fp)
> {
>   return file->currentposition;
> }
>
> In const-world, that should be
>
> long ftell(const FILE *fp)
> {
>    return file->currentposition;
>
> }
>
> because ftell is a read operation.

Maybe.  Since the definition of type FILE is unspecified, we don't
know that ftell() doesn't modify the FILE object (perhaps operations
could be logged in memory).  But since FILE is an opaque type, it
probably doesn't matter a whole lot whether the parameter is const
or not.  No portable C code can do anything with the contents of
a FILE object anyway.

If the parameter were const, an implementation that wants to update
something could just include a pointer to non-const data as a member
of its FILE type.

If a future standard changed the definition to

    long ftell(const FILE *fp);

I don't think it would break any existing portable code.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"