Code-Cleanup: char* -> const char*

Stefan Huehner wrote:

attached patches marks several char* variables as const where they are
initialized with constant strings.

I really wonder how much value there is in using the "const" modifier
very widely. "const" for function parameters is valuable (because it
adds information about the function's behavior to its interface). It
also makes sense to use "const" on global variables, when it reduces the
size of the binary's data segment. Beyond that, you reach the point of
diminishing returns fairly quickly, IMHO. (In C, anyway; it makes more
sense to use it widely in C++, of course.)

I also don't see the value in modifying the regexp code, as that is just
an import of Henry Spencer's regexp package. I'm not sure whether we're
planning on merging any upstream changes any time soon, but making
cosmetic changes to the RE code will only make that more difficult.

Anyway, I'll apply this tomorrow without the RE changes, barring any
objections.

BTW, the preferred format for patches is context diffs, not unified diffs.

-Neil

Neil Conway <neilc@samurai.com> writes:

I also don't see the value in modifying the regexp code, as that is just
an import of Henry Spencer's regexp package.

The same objection applies to most of the proposed changes in /src/port/
since those are generally imports from BSD libc code. I don't mind
cosmetic changes in files that are actually homegrown, but for imported
files it's probably best to avoid unnecessary delta from upstream.

regards, tom lane

Neil Conway wrote:

BTW, the preferred format for patches is context diffs, not unified diffs.

FYI, for the type of diff he is supplying unified diffs are better
because it is single-line changes, and you see the old/new lines next to
each other; the developer's FAQ mentions this.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +