Re: [HACKERS] Add some const decorations to prototypes

On 11/10/17 10:29, Fabien COELHO wrote: > Or basically all is fine, I'm just nitpicking for nothing, shame on me. > > As I said, I rather like more precise declarations. committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] Add some const decorations to prototypes

On 11/10/17 11:42, Fabien COELHO wrote: > After your explanation, and on third thoughts, ISTM that the assignment > should not include "const" in the explicit cast, i.e., use > >extern void * msg_func(void); >const char * msg = (char *) msg_func(); > > The variable or field is constant,

Re: [HACKERS] Add some const decorations to prototypes

Fabien COELHO writes: >> LWLockTrancheArray = (char **) >> MemoryContextAllocZero(TopMemoryContext, >> LWLockTranchesAllocated * sizeof(char *)); > After your explanation, and on third thoughts, ISTM that the assignment > should not include

Re: [HACKERS] Add some const decorations to prototypes

Hello Tom, ISTM That there is still at least one strange cast: +static const char **LWLockTrancheArray = NULL; + LWLockTrancheArray = (const char **) // twice These are not cases of "cheating". This is just the return value of a memory allocation function being cast from

Re: [HACKERS] Add some const decorations to prototypes

Fabien COELHO writes: >>> ISTM That there is still at least one strange cast: +static const char **LWLockTrancheArray = NULL; + LWLockTrancheArray = (const char **) // twice >> These are not cases of "cheating". This is just the return value of a >>

Re: [HACKERS] Add some const decorations to prototypes

Would it make sense that the function returns "const void *", i.e. the cast is not on the const part but on the pointer type part? Or maybe you do not really need a cast, the following code does not generate any warning when compiled with clang & gcc. #include // const void * would be

Re: [HACKERS] Add some const decorations to prototypes

ISTM That there is still at least one strange cast: +static const char **LWLockTrancheArray = NULL; + LWLockTrancheArray = (const char **) // twice These are not cases of "cheating". This is just the return value of a memory allocation function being cast from void * to

Re: [HACKERS] Add some const decorations to prototypes

On 11/4/17 16:50, Fabien COELHO wrote: >>> Just leave it as char*. If you change the endptr argument you're going to >>> force every call site to change their return variable, and some of them >>> would end up having to cast away the const on their end. >> >> OK, here is an updated patch with the

Re: [HACKERS] Add some const decorations to prototypes

Just leave it as char*. If you change the endptr argument you're going to force every call site to change their return variable, and some of them would end up having to cast away the const on their end. OK, here is an updated patch with the controversial bits removed. I'm in general favor

Re: [HACKERS] Add some const decorations to prototypes

On 11/3/17 13:54, Tom Lane wrote: >> Would you prefer leaving the input argument as char *, or change the >> endptr argument to const as well? > > Just leave it as char*. If you change the endptr argument you're going to > force every call site to change their return variable, and some of them >

Re: [HACKERS] Add some const decorations to prototypes

Peter Eisentraut writes: > On 10/31/17 10:56, Tom Lane wrote: >>> Some functions have a strtol()-like behavior >>> where they take in a const char * and return a pointer into that as >>> another argument. In those cases, I added a cast or two. >> ... but I'm

Re: [HACKERS] Add some const decorations to prototypes

On 10/31/17 10:56, Tom Lane wrote: >> Some functions have a strtol()-like behavior >> where they take in a const char * and return a pointer into that as >> another argument. In those cases, I added a cast or two. > ... but I'm not sure that it's an improvement in cases where you have to > cast

Re: [HACKERS] Add some const decorations to prototypes

On Tue, Oct 31, 2017 at 8:26 PM, Tom Lane wrote: > ... but I'm not sure that it's an improvement in cases where you have to > cast away the const somewhere else. I agree. I guess I may be in the minority here but I don't really like decorating things with const too much

Re: [HACKERS] Add some const decorations to prototypes

> On Oct 31, 2017, at 7:46 AM, Peter Eisentraut > wrote: > > Here is a patch that adds const decorations to many char * arguments in > functions. It should have no impact otherwise; there are very few code > changes caused by it. Some functions have a

Re: [HACKERS] Add some const decorations to prototypes

Peter Eisentraut writes: > Here is a patch that adds const decorations to many char * arguments in > functions. It should have no impact otherwise; there are very few code > changes caused by it. +1 in general ... > Some functions have a strtol()-like behavior

[HACKERS] Add some const decorations to prototypes

Here is a patch that adds const decorations to many char * arguments in functions. It should have no impact otherwise; there are very few code changes caused by it. Some functions have a strtol()-like behavior where they take in a const char * and return a pointer into that as another argument.