Re: [HACKERS] Add some const decorations to prototypes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Add some const decorations to prototypes
Date
Msg-id 31668.1510332807@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Add some const decorations to prototypes  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> LWLockTrancheArray = (char **)
>>     MemoryContextAllocZero(TopMemoryContext,
>>                            LWLockTranchesAllocated * sizeof(char *));

> After your explanation, and on third thoughts, ISTM that the assignment 
> should not include "const" in the explicit cast,

Can't get terribly excited about that one way or the other.  I think
the statement would be OK as-is, and it would also be fine as
   LWLockTrancheArray = (const char **)    MemoryContextAllocZero(TopMemoryContext,
LWLockTranchesAllocated* sizeof(const char *));
 

The other two possible combinations are not good of course --- not that
they'd generate invalid code, but that they'd require readers to expend
brain cells convincing themselves that the code wasn't wrong.

> ... and moreover the compiler does not 
> complain without the const.

Arguing on the basis of what your compiler does is a pretty shaky basis.
It's not impossible that someone else's compiler would complain if the
casted-to type isn't identical to the variable's type.  I tend to agree
that a compiler *should* allow "char **" to be cast to "const char **"
silently, but that isn't necessarily what happens in the real world.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] Add some const decorations to prototypes
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Fix bloom WAL tap test