This includes fixing the MSVC copy of ecpg/preproc's version info, which
seems to have been overlooked repeatedly.  Can't we fix that so there are
not two copies??

commit-fest.

Josh Kupershmidt

The tzn value might come from tm->tm_zone, which libc declares as
const, so it's prudent that the upper layers know about this as well.

Use an explicit argument to tell whether to include the time zone in
the output, rather than using some undocumented pointer magic.

Remove some dead code, conditionally declare some items or call
some code, and fix one or two declarations.

Since we now have a global rule in the root .gitignore,
there's no need to keep directory-specific ones as well.

Noted by Peter Eisentraut

Normally nel == 0 works okay because the initial value of "last" will be
less than "base"; but if "base" is zero then the calculation wraps around
and we have a very large (unsigned) value for "last", so that the loop can
be entered and we get a SIGSEGV on a bogus pointer.

This is certainly the proximate cause of the recent reports of Windows
builds crashing on 'infinity'::timestamp --- evidently, they're either not
setting an active timezonetktbl, or setting an empty one.  It's not yet
clear to me why it's only happening on Windows and not happening on any
buildfarm member.  But even if that's due to some bug elsewhere, it seems
wise for this function to not choke on the powerup values of
timezonetktbl/sztimezonetktbl.

I also changed the copy of this code in ecpglib, although I am not sure
whether it's exposed to a similar hazard.

Per report and stack trace from Richard Broersma.

Per recent -hackers discussion. The formats in question are %G and %V,
and cause warnings on MinGW at least. We assume the ecpg application
knows what it's doing if it passes these formats to the library.

interval input "invalid" was specified together with other fields.  Spotted
by Neil Conway with the help of a clang warning.  Although this has been
wrong since the interval code was written more than 10 years ago, it doesn't
affect anything beyond which error message you get for a wrong input, so not
worth back-patching very far.

constant format strings, so that the compiler can more easily check the
formats for correctness.

My initial impression that glibc was measuring the precision in characters
(which is what the Linux man page says it does) was incorrect.  It does take
the precision to be in bytes, but it also tries to truncate the string at a
character boundary.  The bottom line remains the same: it will mess up
if the string is not in the encoding it expects, so we need to avoid %.*s
anytime there's a significant risk of that.  Previous code changes are still
good, but adjust the comments to reflect this knowledge.  Per research by
Hernan Gonzalez.

Depending on which spec you read, field widths and precisions in %s may be
counted either in bytes or characters.  Our code was assuming bytes, which
is wrong at least for glibc's implementation, and in any case libc might
have a different idea of the prevailing encoding than we do.  Hence, for
portable results we must avoid using anything more complex than just "%s"
unless the string to be printed is known to be all-ASCII.

This patch fixes the cases I could find, including the psql formatting
failure reported by Hernan Gonzalez.  In HEAD only, I also added comments
to some places where it appears safe to continue using "%.*s".

Patch done by Zoltán Böszörményi.

based on a patch send in by Böszörményi Zoltán <zb@cybertec.at>.

provided by Andrew.

noise words for the last twelve years, for compatibility with Berkeley-era
output formatting of the special INVALID values for those datatypes.
Considering that the datatypes themselves have been deprecated for awhile,
this is taking backwards compatibility a little far.  Per gripe from Josh
Berkus.

interval style into ecpg.