C99 compliance for src/port/snprintf.c

Started by Tom Laneover 7 years ago95 messages
#1Tom Lane
tgl@sss.pgh.pa.us
1 attachment(s)

I noticed that src/port/snprintf.c still follows the old (pre-C99)
semantics for what to return from snprintf() after buffer overrun.
This seems bad for a couple of reasons:

* It results in potential performance loss in psnprintf and
appendPQExpBufferVA, since those have to fly blind about how much
to enlarge the buffer before retrying.

* Given that we override the system-supplied *printf if it doesn't
support the 'z' width modifier, it seems highly unlikely that we are
still using any snprintf's with pre-C99 semantics, except when this
code is used. So there's not much point in keeping this behavior
as a test case to ensure compatibility with such libraries.

* When we install snprintf.c, port.h forces it to be used everywhere
that includes c.h, including extensions. It seems quite possible that
there is extension code out there that assumes C99 snprintf behavior.
Such code would work today everywhere except Windows, since that's the
only platform made in this century that requires snprintf.c. Between
the existing Windows porting hazard and our nearby discussion about
using snprintf.c on more platforms, I'd say this is a gotcha waiting
to bite somebody.

Hence, PFA a patch that changes snprintf.c to follow C99 by counting
dropped bytes in the result of snprintf(), including in the case where
the passed count is zero.

(I also dropped the tests for str == NULL when count isn't zero; that's
not permitted by either C99 or SUSv2, so I see no reason for this code
to support it. Also, avoid wasting one byte in the local buffer for
*fprintf.)

I'm almost tempted to think that the reasons above make this a
back-patchable bug fix. Comments?

regards, tom lane

Attachments:

c99-compliant-snprintf-result-1.patchtext/x-diff; charset=us-ascii; name=c99-compliant-snprintf-result-1.patchDownload
diff --git a/src/port/snprintf.c b/src/port/snprintf.c
index a184134..851e2ae 100644
*** a/src/port/snprintf.c
--- b/src/port/snprintf.c
***************
*** 2,7 ****
--- 2,8 ----
   * Copyright (c) 1983, 1995, 1996 Eric P. Allman
   * Copyright (c) 1988, 1993
   *	The Regents of the University of California.  All rights reserved.
+  * Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
***************
*** 49,56 ****
   *	SNPRINTF, VSNPRINTF and friends
   *
   * These versions have been grabbed off the net.  They have been
!  * cleaned up to compile properly and support for most of the Single Unix
!  * Specification has been added.  Remaining unimplemented features are:
   *
   * 1. No locale support: the radix character is always '.' and the '
   * (single quote) format flag is ignored.
--- 50,57 ----
   *	SNPRINTF, VSNPRINTF and friends
   *
   * These versions have been grabbed off the net.  They have been
!  * cleaned up to compile properly and support for most of the C99
!  * specification has been added.  Remaining unimplemented features are:
   *
   * 1. No locale support: the radix character is always '.' and the '
   * (single quote) format flag is ignored.
***************
*** 64,88 ****
   * 5. Space and '#' flags are not implemented.
   *
   *
!  * The result values of these functions are not the same across different
!  * platforms.  This implementation is compatible with the Single Unix Spec:
   *
!  * 1. -1 is returned only if processing is abandoned due to an invalid
!  * parameter, such as incorrect format string.  (Although not required by
!  * the spec, this happens only when no characters have yet been transmitted
!  * to the destination.)
   *
!  * 2. For snprintf and sprintf, 0 is returned if str == NULL or count == 0;
!  * no data has been stored.
   *
!  * 3. Otherwise, the number of bytes actually transmitted to the destination
!  * is returned (excluding the trailing '\0' for snprintf and sprintf).
   *
!  * For snprintf with nonzero count, the result cannot be more than count-1
!  * (a trailing '\0' is always stored); it is not possible to distinguish
!  * buffer overrun from exact fit.  This is unlike some implementations that
!  * return the number of bytes that would have been needed for the complete
!  * result string.
   */
  
  /**************************************************************
--- 65,88 ----
   * 5. Space and '#' flags are not implemented.
   *
   *
!  * Historically the result values of sprintf/snprintf varied across platforms.
!  * This implementation now follows the C99 standard:
   *
!  * 1. -1 is returned if an error is detected in the format string, or if
!  * a write to the target stream fails (as reported by fwrite).  Note that
!  * overrunning snprintf's target buffer is *not* an error.
   *
!  * 2. For successful writes to streams, the actual number of bytes written
!  * to the stream is returned.
   *
!  * 3. For successful sprintf/snprintf, the number of bytes that would have
!  * been written to an infinite-size buffer (excluding the trailing '\0')
!  * is returned.  snprintf will truncate its output to fit in the buffer
!  * (ensuring a trailing '\0' unless count == 0), but this is not reflected
!  * in the function result.
   *
!  * snprintf buffer overrun can be detected by checking for function result
!  * greater than or equal to the supplied count.
   */
  
  /**************************************************************
***************
*** 101,115 ****
  #undef	fprintf
  #undef	printf
  
! /* Info about where the formatted output is going */
  typedef struct
  {
  	char	   *bufptr;			/* next buffer output position */
  	char	   *bufstart;		/* first buffer element */
! 	char	   *bufend;			/* last buffer element, or NULL */
  	/* bufend == NULL is for sprintf, where we assume buf is big enough */
  	FILE	   *stream;			/* eventual output destination, or NULL */
! 	int			nchars;			/* # chars already sent to stream */
  	bool		failed;			/* call is a failure; errno is set */
  } PrintfTarget;
  
--- 101,127 ----
  #undef	fprintf
  #undef	printf
  
! /*
!  * Info about where the formatted output is going.
!  *
!  * dopr and subroutines will not write at/past bufend, but snprintf
!  * reserves one byte, ensuring it may place the trailing '\0' there.
!  *
!  * In snprintf, we use nchars to count the number of bytes dropped on the
!  * floor due to buffer overrun.  The correct result of snprintf is thus
!  * (bufptr - bufstart) + nchars.  (This isn't as inconsistent as it might
!  * seem: nchars is the number of emitted bytes that are not in the buffer now,
!  * either because we sent them to the stream or because we couldn't fit them
!  * into the buffer to begin with.)
!  */
  typedef struct
  {
  	char	   *bufptr;			/* next buffer output position */
  	char	   *bufstart;		/* first buffer element */
! 	char	   *bufend;			/* last+1 buffer element, or NULL */
  	/* bufend == NULL is for sprintf, where we assume buf is big enough */
  	FILE	   *stream;			/* eventual output destination, or NULL */
! 	int			nchars;			/* # chars sent to stream, or dropped */
  	bool		failed;			/* call is a failure; errno is set */
  } PrintfTarget;
  
*************** int
*** 147,163 ****
  pg_vsnprintf(char *str, size_t count, const char *fmt, va_list args)
  {
  	PrintfTarget target;
  
! 	if (str == NULL || count == 0)
! 		return 0;
  	target.bufstart = target.bufptr = str;
  	target.bufend = str + count - 1;
  	target.stream = NULL;
! 	/* target.nchars is unused in this case */
  	target.failed = false;
  	dopr(&target, fmt, args);
  	*(target.bufptr) = '\0';
! 	return target.failed ? -1 : (target.bufptr - target.bufstart);
  }
  
  int
--- 159,186 ----
  pg_vsnprintf(char *str, size_t count, const char *fmt, va_list args)
  {
  	PrintfTarget target;
+ 	char		onebyte[1];
  
! 	/*
! 	 * C99 allows the case str == NULL when count == 0.  Rather than
! 	 * special-casing this situation further down, we substitute a one-byte
! 	 * local buffer.  Callers cannot tell, since the function result doesn't
! 	 * depend on count.
! 	 */
! 	if (count == 0)
! 	{
! 		str = onebyte;
! 		count = 1;
! 	}
  	target.bufstart = target.bufptr = str;
  	target.bufend = str + count - 1;
  	target.stream = NULL;
! 	target.nchars = 0;
  	target.failed = false;
  	dopr(&target, fmt, args);
  	*(target.bufptr) = '\0';
! 	return target.failed ? -1 : (target.bufptr - target.bufstart
! 								 + target.nchars);
  }
  
  int
*************** pg_vsprintf(char *str, const char *fmt, 
*** 177,192 ****
  {
  	PrintfTarget target;
  
- 	if (str == NULL)
- 		return 0;
  	target.bufstart = target.bufptr = str;
  	target.bufend = NULL;
  	target.stream = NULL;
! 	/* target.nchars is unused in this case */
  	target.failed = false;
  	dopr(&target, fmt, args);
  	*(target.bufptr) = '\0';
! 	return target.failed ? -1 : (target.bufptr - target.bufstart);
  }
  
  int
--- 200,214 ----
  {
  	PrintfTarget target;
  
  	target.bufstart = target.bufptr = str;
  	target.bufend = NULL;
  	target.stream = NULL;
! 	target.nchars = 0;			/* not really used in this case */
  	target.failed = false;
  	dopr(&target, fmt, args);
  	*(target.bufptr) = '\0';
! 	return target.failed ? -1 : (target.bufptr - target.bufstart
! 								 + target.nchars);
  }
  
  int
*************** pg_vfprintf(FILE *stream, const char *fm
*** 213,219 ****
  		return -1;
  	}
  	target.bufstart = target.bufptr = buffer;
! 	target.bufend = buffer + sizeof(buffer) - 1;
  	target.stream = stream;
  	target.nchars = 0;
  	target.failed = false;
--- 235,241 ----
  		return -1;
  	}
  	target.bufstart = target.bufptr = buffer;
! 	target.bufend = buffer + sizeof(buffer);	/* use the whole buffer */
  	target.stream = stream;
  	target.nchars = 0;
  	target.failed = false;
*************** flushbuffer(PrintfTarget *target)
*** 256,261 ****
--- 278,287 ----
  {
  	size_t		nc = target->bufptr - target->bufstart;
  
+ 	/*
+ 	 * Don't write anything if we already failed; this is to ensure we
+ 	 * preserve the original failure's errno.
+ 	 */
  	if (!target->failed && nc > 0)
  	{
  		size_t		written;
*************** dostr(const char *str, int slen, PrintfT
*** 1035,1041 ****
  		{
  			/* buffer full, can we dump to stream? */
  			if (target->stream == NULL)
! 				return;			/* no, lose the data */
  			flushbuffer(target);
  			continue;
  		}
--- 1061,1070 ----
  		{
  			/* buffer full, can we dump to stream? */
  			if (target->stream == NULL)
! 			{
! 				target->nchars += slen; /* no, lose the data */
! 				return;
! 			}
  			flushbuffer(target);
  			continue;
  		}
*************** dopr_outch(int c, PrintfTarget *target)
*** 1054,1060 ****
  	{
  		/* buffer full, can we dump to stream? */
  		if (target->stream == NULL)
! 			return;				/* no, lose the data */
  		flushbuffer(target);
  	}
  	*(target->bufptr++) = c;
--- 1083,1092 ----
  	{
  		/* buffer full, can we dump to stream? */
  		if (target->stream == NULL)
! 		{
! 			target->nchars++;	/* no, lose the data */
! 			return;
! 		}
  		flushbuffer(target);
  	}
  	*(target->bufptr++) = c;
#2Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#1)
Re: C99 compliance for src/port/snprintf.c

On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I'm almost tempted to think that the reasons above make this a
back-patchable bug fix. Comments?

No objections to changing the behavior. Have you checked whether
there are any noticeable performance consequences?

Back-patching seems a bit aggressive to me considering that the danger
is hypothetical. I'd want to have some tangible evidence that
back-patching was going help somebody. For all we know somebody's got
an extension which they only use on Windows that happens to be relying
on the current behavior, although more likely still (IMHO) is that it
there is little or no code relying on either behavior.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#2)
Re: C99 compliance for src/port/snprintf.c

Robert Haas <robertmhaas@gmail.com> writes:

On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I'm almost tempted to think that the reasons above make this a
back-patchable bug fix. Comments?

No objections to changing the behavior. Have you checked whether
there are any noticeable performance consequences?

Hard to believe there could be any performance loss. The normal (non
buffer overflowing) code path gets two additional instructions, storing
zero into .nchars and then adding it to the result. There would be more
work added to buffer-overflow cases, but we'd surely more than win that
back by avoiding repeated repalloc-and-try-again cycles.

Back-patching seems a bit aggressive to me considering that the danger
is hypothetical. I'd want to have some tangible evidence that
back-patching was going help somebody. For all we know somebody's got
an extension which they only use on Windows that happens to be relying
on the current behavior, although more likely still (IMHO) is that it
there is little or no code relying on either behavior.

Yeah, it's theoretically possible that there's somebody out there who's
depending on the pre-C99 behavior and never tested their code anywhere
but Windows. But come on, how likely is that really, compared to the
much more plausible risks I already cited? It's not even that easy
to imagine how someone would construct code that had such a dependency
while not being outright buggy in the face of buffer overrun.

BTW, independently of whether to back-patch, it strikes me that what
we ought to do in HEAD (after applying this) is to just assume we have
C99-compliant behavior, and rip out the baroque logic in psnprintf
and appendPQExpBufferVA that tries to deal with pre-C99 snprintf.
I don't expect that'd save any really meaningful number of cycles,
but at least it'd buy back the two added instructions mentioned above.
I suppose we could put in a configure check that verifies whether
the system snprintf returns the right value for overrun cases, though
it's hard to believe there are any platforms that pass the 'z' check
and would fail this one.

regards, tom lane

#4Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#3)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-15 11:41:46 -0400, Tom Lane wrote:

BTW, independently of whether to back-patch, it strikes me that what
we ought to do in HEAD (after applying this) is to just assume we have
C99-compliant behavior, and rip out the baroque logic in psnprintf
and appendPQExpBufferVA that tries to deal with pre-C99 snprintf.
I don't expect that'd save any really meaningful number of cycles,
but at least it'd buy back the two added instructions mentioned above.
I suppose we could put in a configure check that verifies whether
the system snprintf returns the right value for overrun cases, though
it's hard to believe there are any platforms that pass the 'z' check
and would fail this one.

We could just mandate C99, more generally.

/me goes and hides in a bush.

#5Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Robert Haas (#2)
Re: C99 compliance for src/port/snprintf.c

On 2018-Aug-15, Robert Haas wrote:

On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I'm almost tempted to think that the reasons above make this a
back-patchable bug fix. Comments?

No objections to changing the behavior. Have you checked whether
there are any noticeable performance consequences?

Back-patching seems a bit aggressive to me considering that the danger
is hypothetical.

That was my first thought too, and my preferred path would be to make
this master-only and only consider a backpatch later if we find some
practical reason to do so.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#6Robert Haas
robertmhaas@gmail.com
In reply to: Andres Freund (#4)
Re: C99 compliance for src/port/snprintf.c

On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund <andres@anarazel.de> wrote:

We could just mandate C99, more generally.

/me goes and hides in a bush.

It's hard to believe that would cost much. Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability. But it's kind
of difficult to believe that we really need to worry about people
still running 20-year old compilers very much. My first exposure to
Tom arguing that we ought to continue supporting C89 was about a
decade ago, but the argument that people might still have older
systems in service was a lot more plausible then than it is now.

BTW, I think a bush is probably not a nearly sufficient place to hide.
The wrath of Tom will find you wherever you may go... :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#7Stephen Frost
sfrost@snowman.net
In reply to: Andres Freund (#4)
Re: C99 compliance for src/port/snprintf.c

Greetings,

* Andres Freund (andres@anarazel.de) wrote:

On 2018-08-15 11:41:46 -0400, Tom Lane wrote:

BTW, independently of whether to back-patch, it strikes me that what
we ought to do in HEAD (after applying this) is to just assume we have
C99-compliant behavior, and rip out the baroque logic in psnprintf
and appendPQExpBufferVA that tries to deal with pre-C99 snprintf.
I don't expect that'd save any really meaningful number of cycles,
but at least it'd buy back the two added instructions mentioned above.
I suppose we could put in a configure check that verifies whether
the system snprintf returns the right value for overrun cases, though
it's hard to believe there are any platforms that pass the 'z' check
and would fail this one.

We could just mandate C99, more generally.

*cough* +1 *cough*

/me goes and hides in a bush.

/me runs

Thanks!

Stephen

#8Andres Freund
andres@anarazel.de
In reply to: Robert Haas (#6)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-15 12:01:28 -0400, Robert Haas wrote:

On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund <andres@anarazel.de> wrote:

We could just mandate C99, more generally.

/me goes and hides in a bush.

It's hard to believe that would cost much.

Yea.

Personally, I'd prefer to continue avoiding // comments and
intermingled declarations of variables and code on grounds of style
and readability.

I don't really care much about either. The calculus for intermingled
declarations would personally change the minute that we decided to allow
some C++ - allowing for scoped locks etc via RAII - but not earlier.

The thing I'd really want is designated initializers for structs. Makes
code for statically allocated structs *so* much more readable. And guess
who's working on code that adds statically allocated structs with lots
of members...

BTW, I think a bush is probably not a nearly sufficient place to hide.
The wrath of Tom will find you wherever you may go... :-)

That's why I keep moving. At 200 mph on a train :P. A continent away.

Greetings,

Andres Freund

#9Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#6)
Re: C99 compliance for src/port/snprintf.c

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund <andres@anarazel.de> wrote:

We could just mandate C99, more generally.

/me goes and hides in a bush.

It's hard to believe that would cost much.

I think we have done that, piece by piece, where it was actually buying us
something. In particular we've gradually moved the goalposts for *printf
compliance, and I'm proposing here to move them a bit further. I'm not
sure what "we're going to insist on C99" even means concretely, given
this position ...

Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.

... which I agree with.

But it's kind
of difficult to believe that we really need to worry about people
still running 20-year old compilers very much.

Sure. It's been a long time since anybody worried about those as
optimization targets, for instance. Still, I'm not in favor of
actively breaking compatibility unless it buys us something.

regards, tom lane

#10Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#5)
Re: C99 compliance for src/port/snprintf.c

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

On 2018-Aug-15, Robert Haas wrote:

Back-patching seems a bit aggressive to me considering that the danger
is hypothetical.

That was my first thought too, and my preferred path would be to make
this master-only and only consider a backpatch later if we find some
practical reason to do so.

Meh --- the hazards of back-patching seem to me to be more hypothetical
than the benefits. Still, I seem to be in the minority, so I withdraw
the proposal to back-patch.

regards, tom lane

#11David Steele
david@pgmasters.net
In reply to: Tom Lane (#9)
Re: C99 compliance for src/port/snprintf.c

On 8/15/18 12:17 PM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.

... which I agree with.

We already have -Wdeclaration-after-statement to prevent mixed
declarations. Not sure what to do about comments except manual enforcement.

But it's kind
of difficult to believe that we really need to worry about people
still running 20-year old compilers very much.

Sure. It's been a long time since anybody worried about those as
optimization targets, for instance. Still, I'm not in favor of
actively breaking compatibility unless it buys us something.

We use C99 for the pgBackRest project and we've found designated
initializers, compound declarations, and especially variadic macros to
be very helpful. Only the latter really provides new functionality but
simplifying and clarifying code is always a bonus.

So, +1 from me!

Regards,
--
-David
david@pgmasters.net

#12Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tom Lane (#10)
Re: C99 compliance for src/port/snprintf.c

I wrote:

Meh --- the hazards of back-patching seem to me to be more hypothetical
than the benefits. Still, I seem to be in the minority, so I withdraw
the proposal to back-patch.

Actually, after digging around a bit, I'm excited about this again.
There are only a couple dozen places in our tree that pay any attention
to the result of (v)snprintf, but with the exception of psnprintf,
appendPQExpBufferVA, and one or two other places, *they're all assuming
C99 semantics*, and will fail to detect buffer overflow with the pre-C99
behavior.

Probably a lot of these are not live bugs because buffer overrun is
not ever going to occur in practice. But at least pg_upgrade and
pg_regress are constructing command strings including externally
supplied paths, so overrun doesn't seem impossible. If it happened,
they'd merrily proceed to execute a truncated command.

If we don't backpatch the snprintf change, we're morally obliged to
back-patch some other fix for these places. At least one of them,
in plperl's pport.h, is not our code and so changing it seems like
a bad idea.

Still want to argue for no backpatch?

regards, tom lane

PS: I also found a couple of places that are just wrong regardless
of semantics: they're checking overflow by "result > bufsize", not
"result >= bufsize". Will fix those in any case.

#13Tom Lane
tgl@sss.pgh.pa.us
In reply to: David Steele (#11)
Re: C99 compliance for src/port/snprintf.c

David Steele <david@pgmasters.net> writes:

On 8/15/18 12:17 PM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.

... which I agree with.

We already have -Wdeclaration-after-statement to prevent mixed
declarations. Not sure what to do about comments except manual enforcement.

pgindent will change // comments to /* style, so at least on the timescale
of a release cycle, we have enforcement for that.

regards, tom lane

#14Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Tom Lane (#9)
Re: C99 compliance for src/port/snprintf.c

On 08/15/2018 12:17 PM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.

... which I agree with.

A decade or so ago I would have strongly agreed with you. But the
language trend seems to be in the other direction. And there is
something to be said for declaration near use without having to use an
inner block. I'm not advocating that we change policy, however.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#15Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#14)
Re: C99 compliance for src/port/snprintf.c

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

On 08/15/2018 12:17 PM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.

... which I agree with.

A decade or so ago I would have strongly agreed with you. But the
language trend seems to be in the other direction. And there is
something to be said for declaration near use without having to use an
inner block. I'm not advocating that we change policy, however.

FWIW, the issue I've got with what C99 did is that you can narrow the
*start* of the scope of a local variable easily, but not the *end* of
its scope, which seems to me to be solving at most half of the problem.
To solve the whole problem, you end up needing a nested block anyway.

I do dearly miss the ability to easily limit the scope of a loop's
control variable to just the loop, eg

for (int i = 0; ...) { ... }

But AFAIK that's C++ not C99.

regards, tom lane

#16Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Tom Lane (#15)
Re: C99 compliance for src/port/snprintf.c

On 08/15/2018 03:18 PM, Tom Lane wrote:

FWIW, the issue I've got with what C99 did is that you can narrow the
*start* of the scope of a local variable easily, but not the *end* of
its scope, which seems to me to be solving at most half of the problem.
To solve the whole problem, you end up needing a nested block anyway.

I do dearly miss the ability to easily limit the scope of a loop's
control variable to just the loop, eg

for (int i = 0; ...) { ... }

But AFAIK that's C++ not C99.

Agree completely.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#17David Steele
david@pgmasters.net
In reply to: Tom Lane (#15)
Re: C99 compliance for src/port/snprintf.c

On 8/15/18 3:18 PM, Tom Lane wrote:

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

On 08/15/2018 12:17 PM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Personally, I'd prefer to
continue avoiding // comments and intermingled declarations of
variables and code on grounds of style and readability.

... which I agree with.

A decade or so ago I would have strongly agreed with you. But the
language trend seems to be in the other direction. And there is
something to be said for declaration near use without having to use an
inner block. I'm not advocating that we change policy, however.

FWIW, the issue I've got with what C99 did is that you can narrow the
*start* of the scope of a local variable easily, but not the *end* of
its scope, which seems to me to be solving at most half of the problem.
To solve the whole problem, you end up needing a nested block anyway.

I do dearly miss the ability to easily limit the scope of a loop's
control variable to just the loop, eg

for (int i = 0; ...) { ... }

But AFAIK that's C++ not C99.

This works in C99 -- and I'm a really big fan.

--
-David
david@pgmasters.net

#18Tom Lane
tgl@sss.pgh.pa.us
In reply to: David Steele (#17)
Re: C99 compliance for src/port/snprintf.c

David Steele <david@pgmasters.net> writes:

On 8/15/18 3:18 PM, Tom Lane wrote:

I do dearly miss the ability to easily limit the scope of a loop's
control variable to just the loop, eg
for (int i = 0; ...) { ... }
But AFAIK that's C++ not C99.

This works in C99 -- and I'm a really big fan.

It does? [ checks standard... ] Oh wow:

6.8.5 Iteration statements

Syntax

iteration-statement:
while ( expression ) statement
do statement while ( expression ) ;
for ( expr-opt ; expr-opt ; expr-opt ) statement
for ( declaration ; expr-opt ; expr-opt ) statement

I'd always thought this was only in C++. This alone might be a sufficient
reason to drop C89 compiler support ...

regards, tom lane

#19Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#18)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-15 15:57:43 -0400, Tom Lane wrote:

I'd always thought this was only in C++. This alone might be a sufficient
reason to drop C89 compiler support ...

It's also IIRC reasonably widely supported from before C99. So, for the
sake of designated initializers, for loop scoping, snprintf, let's do
this in master?

Greetings,

Andres Freund

#20Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#12)
Re: C99 compliance for src/port/snprintf.c

On 2018-08-15 14:05:29 -0400, Tom Lane wrote:

I wrote:

Meh --- the hazards of back-patching seem to me to be more hypothetical
than the benefits. Still, I seem to be in the minority, so I withdraw
the proposal to back-patch.

Actually, after digging around a bit, I'm excited about this again.
There are only a couple dozen places in our tree that pay any attention
to the result of (v)snprintf, but with the exception of psnprintf,
appendPQExpBufferVA, and one or two other places, *they're all assuming
C99 semantics*, and will fail to detect buffer overflow with the pre-C99
behavior.

Probably a lot of these are not live bugs because buffer overrun is
not ever going to occur in practice. But at least pg_upgrade and
pg_regress are constructing command strings including externally
supplied paths, so overrun doesn't seem impossible. If it happened,
they'd merrily proceed to execute a truncated command.

If we don't backpatch the snprintf change, we're morally obliged to
back-patch some other fix for these places. At least one of them,
in plperl's pport.h, is not our code and so changing it seems like
a bad idea.

Still want to argue for no backpatch?

regards, tom lane

PS: I also found a couple of places that are just wrong regardless
of semantics: they're checking overflow by "result > bufsize", not
"result >= bufsize". Will fix those in any case.

I'm a bit confused. Why did you just backpatch this ~two hours after
people objected to the idea? Even if it were during my current work
hours, I don't even read mail that often if I'm hacking on something
complicated.

Greetings,

Andres Freund

#21Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#19)
Re: C99 compliance for src/port/snprintf.c

Andres Freund <andres@anarazel.de> writes:

On 2018-08-15 15:57:43 -0400, Tom Lane wrote:

I'd always thought this was only in C++. This alone might be a sufficient
reason to drop C89 compiler support ...

It's also IIRC reasonably widely supported from before C99. So, for the
sake of designated initializers, for loop scoping, snprintf, let's do
this in master?

Nitpick: snprintf is an independent concern: that's from the C library,
not from the compiler. To drive the point home, I could still test
master on "gaur" if I were to install a just-slightly-newer gcc on that
machine (its existing gcc installation isn't native either...); but
replacing its libc is a nonstarter.

Experimenting here says that even reasonably modern gcc's won't take
declarations-inside-for without "--std=c99" or such. No idea about
other compilers. So we'd have a little bit of work to do on
configuration before we could open the floodgates on this.

regards, tom lane

#22Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#20)
Re: C99 compliance for src/port/snprintf.c

Andres Freund <andres@anarazel.de> writes:

On 2018-08-15 14:05:29 -0400, Tom Lane wrote:

Still want to argue for no backpatch?

I'm a bit confused. Why did you just backpatch this ~two hours after
people objected to the idea? Even if it were during my current work
hours, I don't even read mail that often if I'm hacking on something
complicated.

If a consensus emerges to deal with this some other way, reverting
isn't hard. But I think it's pretty clear at this point that we're
dealing with real bugs versus entirely hypothetical bugs, and that's
not a decision that's hard to make IMO.

regards, tom lane

#23Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#21)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-15 18:13:59 -0400, Tom Lane wrote:

Experimenting here says that even reasonably modern gcc's won't take
declarations-inside-for without "--std=c99" or such. No idea about
other compilers. So we'd have a little bit of work to do on
configuration before we could open the floodgates on this.

I think autoconf's magic knows about most of that:

— Macro: AC_PROG_CC_C99

If the C compiler is not in C99 mode by default, try to add an
option to output variable CC to make it so. This macro tries various
options that select C99 on some system or another. It considers the
compiler to be in C99 mode if it handles _Bool, flexible arrays,
inline, long long int, mixed code and declarations, named
initialization of structs, restrict, varargs macros, variable
declarations in for loops and variable length arrays.

After calling this macro you can check whether the C compiler has
been set to accept C99; if not, the shell variable ac_cv_prog_cc_c99
is set to ‘no’. ~

I think we could get a start by adding that test to configure, without
relying on it for now (i.e. keeping mylodon with -Wc99-extensions
-Werror=c99-extensions alive). That'd tell us about which machines,
besides presumably gaur, we'd need to either kick to the curb or change.

Greetings,

Andres Freund

#24Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#23)
Re: C99 compliance for src/port/snprintf.c

Andres Freund <andres@anarazel.de> writes:

On 2018-08-15 18:13:59 -0400, Tom Lane wrote:

Experimenting here says that even reasonably modern gcc's won't take
declarations-inside-for without "--std=c99" or such.

I think autoconf's magic knows about most of that:
— Macro: AC_PROG_CC_C99

Ah, of course. What about the MSVC build?

I think we could get a start by adding that test to configure, without
relying on it for now (i.e. keeping mylodon with -Wc99-extensions
-Werror=c99-extensions alive). That'd tell us about which machines,
besides presumably gaur, we'd need to either kick to the curb or change.

Sure, no objection to putting that in just to see how much of the
buildfarm can handle it. If the answer turns out to be "a lot",
we might have to reconsider, but gathering data seems like the
first thing to do.

regards, tom lane

#25Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#24)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-15 18:31:10 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-15 18:13:59 -0400, Tom Lane wrote:

Experimenting here says that even reasonably modern gcc's won't take
declarations-inside-for without "--std=c99" or such.

I think autoconf's magic knows about most of that:
— Macro: AC_PROG_CC_C99

Ah, of course. What about the MSVC build?

It looks like it mostly just enables that by default. But I only looked
cursorily. It's a bit annoying because that makes it harder to be sure
which animals support what. Looks like e.g. hammerkop (supposedly msvc
2005) might not support the subset we want; not that I'd loose sleep
over raising the minimum msvc in master a bit.

I think we could get a start by adding that test to configure, without
relying on it for now (i.e. keeping mylodon with -Wc99-extensions
-Werror=c99-extensions alive). That'd tell us about which machines,
besides presumably gaur, we'd need to either kick to the curb or change.

Sure, no objection to putting that in just to see how much of the
buildfarm can handle it. If the answer turns out to be "a lot",
we might have to reconsider, but gathering data seems like the
first thing to do.

Cool. Too late today (in Europe for a few more days), but I'll try to
come up with something tomorrow.

Greetings,

Andres Freund

#26Thomas Munro
thomas.munro@enterprisedb.com
In reply to: Andres Freund (#25)
Re: C99 compliance for src/port/snprintf.c

On Thu, Aug 16, 2018 at 10:40 AM, Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2018-08-15 18:31:10 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-15 18:13:59 -0400, Tom Lane wrote:

Experimenting here says that even reasonably modern gcc's won't take
declarations-inside-for without "--std=c99" or such.

I think autoconf's magic knows about most of that:
— Macro: AC_PROG_CC_C99

Ah, of course. What about the MSVC build?

It looks like it mostly just enables that by default. But I only looked
cursorily. It's a bit annoying because that makes it harder to be sure
which animals support what. Looks like e.g. hammerkop (supposedly msvc
2005) might not support the subset we want; not that I'd loose sleep
over raising the minimum msvc in master a bit.

Really? I am not an MSVC user but I had the impression that their C
mode (/TC or files named .c) was stuck on C89/C90 as a matter of
policy, as Herb Sutter explained here (though maybe the situation has
changed since then):

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

That's presumably why cfbot's appveyor build always complains about
people declaring variables after statements. To allow that particular
language feature, it looks like you have to tell it that your .c file
is really a C++ program with /TP. But that opens a separate can of
worms, doesn't it?

--
Thomas Munro
http://www.enterprisedb.com

#27Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas Munro (#26)
Re: C99 compliance for src/port/snprintf.c

Thomas Munro <thomas.munro@enterprisedb.com> writes:

Really? I am not an MSVC user but I had the impression that their C
mode (/TC or files named .c) was stuck on C89/C90 as a matter of
policy, as Herb Sutter explained here (though maybe the situation has
changed since then):

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Hm, I read that and what it says is that they don't plan to support
C99 features that aren't also in C++. But this one surely is.

How you turn it on (without enabling all of C++) is not very clear
though.

regards, tom lane

#28Andres Freund
andres@anarazel.de
In reply to: Thomas Munro (#26)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-16 10:54:01 +1200, Thomas Munro wrote:

Really? I am not an MSVC user but I had the impression that their C
mode (/TC or files named .c) was stuck on C89/C90 as a matter of
policy, as Herb Sutter explained here (though maybe the situation has
changed since then):

They revised their position gradually, starting soon after. They claim
full C99 "language" (vs library, which is also pretty complete)
compliance now. I've not yet bothered to fully figure out which version
supports what however. Nor am I really sure about the whole flag thing,
it appears there's a gui element to choose, which we might need to mirror on
the xml level.

A bit of googling shows
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/hh409293(v=vs.120)
"
Supports these ISO C99 language features:

_Bool

Compound literals.

Designated initializers.

Mixing declarations with code.
"

which I think is what we roughly would want. So it looks like msvc 2013
might be the relevant requirement.

That's presumably why cfbot's appveyor build always complains about
people declaring variables after statements.

IIRC even in older versions there's a flag to allow that.

To allow that particular language feature, it looks like you have to
tell it that your .c file is really a C++ program with /TP. But that
opens a separate can of worms, doesn't it?

Yea, I don't think we want to go there by default soon.

Greetings,

Andres Freund

#29Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tom Lane (#3)
1 attachment(s)
Re: C99 compliance for src/port/snprintf.c

I wrote:

BTW, independently of whether to back-patch, it strikes me that what
we ought to do in HEAD (after applying this) is to just assume we have
C99-compliant behavior, and rip out the baroque logic in psnprintf
and appendPQExpBufferVA that tries to deal with pre-C99 snprintf.

Here's a proposed patch for that. It also gets rid of some ancient
code that tried to deal with snprintfs that were outright broken,
such as writing past the end of the specified buffer. Even if anyone
is still using platforms where that's a problem, I'd expect that we'd
have rejected the system snprintf thanks to configure's feature checks.

regards, tom lane

Attachments:

assume-snprintf-follows-c99.patchtext/x-diff; charset=us-ascii; name=assume-snprintf-follows-c99.patchDownload
diff --git a/config/c-library.m4 b/config/c-library.m4
index 4446a5b..6bcfcee 100644
*** a/config/c-library.m4
--- b/config/c-library.m4
*************** int main()
*** 238,243 ****
--- 238,270 ----
  AC_MSG_RESULT([$pgac_cv_snprintf_size_t_support])
  ])# PGAC_FUNC_SNPRINTF_SIZE_T_SUPPORT
  
+ # PGAC_FUNC_SNPRINTF_C99_RESULT
+ # -----------------------------
+ # Determine whether snprintf returns the desired buffer length when
+ # it overruns the actual buffer length.  That's required by C99 and POSIX
+ # but ancient platforms don't behave that way, so we must test.
+ #
+ AC_DEFUN([PGAC_FUNC_SNPRINTF_C99_RESULT],
+ [AC_MSG_CHECKING([whether snprintf reports buffer overrun per C99])
+ AC_CACHE_VAL(pgac_cv_snprintf_c99_result,
+ [AC_RUN_IFELSE([AC_LANG_SOURCE([[#include <stdio.h>
+ #include <string.h>
+ 
+ int main()
+ {
+   char buf[10];
+ 
+   if (snprintf(buf, sizeof(buf), "12345678901234567890") != 20)
+     return 1;
+   return 0;
+ }]])],
+ [pgac_cv_snprintf_c99_result=yes],
+ [pgac_cv_snprintf_c99_result=no],
+ [pgac_cv_snprintf_c99_result=cross])
+ ])dnl AC_CACHE_VAL
+ AC_MSG_RESULT([$pgac_cv_snprintf_c99_result])
+ ])# PGAC_FUNC_SNPRINTF_C99_RESULT
+ 
  
  # PGAC_TYPE_LOCALE_T
  # ------------------
diff --git a/configure b/configure
index 067fc43..863d07f 100755
*** a/configure
--- b/configure
*************** fi
*** 15965,15971 ****
  # Run tests below here
  # --------------------
  
! # Force use of our snprintf if system's doesn't do arg control
  # See comment above at snprintf test for details.
  if test "$enable_nls" = yes -a "$pgac_need_repl_snprintf" = no; then
    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether snprintf supports argument control" >&5
--- 15965,15971 ----
  # Run tests below here
  # --------------------
  
! # For NLS, force use of our snprintf if system's doesn't do arg control.
  # See comment above at snprintf test for details.
  if test "$enable_nls" = yes -a "$pgac_need_repl_snprintf" = no; then
    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether snprintf supports argument control" >&5
*************** $as_echo "$pgac_cv_snprintf_size_t_suppo
*** 16259,16264 ****
--- 16259,16308 ----
    fi
  fi
  
+ # Force use of our snprintf if the system's doesn't handle buffer overrun
+ # as specified by C99.
+ if test "$pgac_need_repl_snprintf" = no; then
+   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether snprintf reports buffer overrun per C99" >&5
+ $as_echo_n "checking whether snprintf reports buffer overrun per C99... " >&6; }
+ if ${pgac_cv_snprintf_c99_result+:} false; then :
+   $as_echo_n "(cached) " >&6
+ else
+   if test "$cross_compiling" = yes; then :
+   pgac_cv_snprintf_c99_result=cross
+ else
+   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h.  */
+ #include <stdio.h>
+ #include <string.h>
+ 
+ int main()
+ {
+   char buf[10];
+ 
+   if (snprintf(buf, sizeof(buf), "12345678901234567890") != 20)
+     return 1;
+   return 0;
+ }
+ _ACEOF
+ if ac_fn_c_try_run "$LINENO"; then :
+   pgac_cv_snprintf_c99_result=yes
+ else
+   pgac_cv_snprintf_c99_result=no
+ fi
+ rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
+   conftest.$ac_objext conftest.beam conftest.$ac_ext
+ fi
+ 
+ 
+ fi
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_snprintf_c99_result" >&5
+ $as_echo "$pgac_cv_snprintf_c99_result" >&6; }
+ 
+   if test "$pgac_cv_snprintf_c99_result" != yes; then
+     pgac_need_repl_snprintf=yes
+   fi
+ fi
+ 
  # Now we have checked all the reasons to replace snprintf
  if test $pgac_need_repl_snprintf = yes; then
  
diff --git a/configure.in b/configure.in
index 49257e5..1c529e7 100644
*** a/configure.in
--- b/configure.in
*************** for the exact reason.]])],
*** 1805,1811 ****
  # Run tests below here
  # --------------------
  
! # Force use of our snprintf if system's doesn't do arg control
  # See comment above at snprintf test for details.
  if test "$enable_nls" = yes -a "$pgac_need_repl_snprintf" = no; then
    PGAC_FUNC_SNPRINTF_ARG_CONTROL
--- 1805,1811 ----
  # Run tests below here
  # --------------------
  
! # For NLS, force use of our snprintf if system's doesn't do arg control.
  # See comment above at snprintf test for details.
  if test "$enable_nls" = yes -a "$pgac_need_repl_snprintf" = no; then
    PGAC_FUNC_SNPRINTF_ARG_CONTROL
*************** if test "$pgac_need_repl_snprintf" = no;
*** 1857,1862 ****
--- 1857,1871 ----
    fi
  fi
  
+ # Force use of our snprintf if the system's doesn't handle buffer overrun
+ # as specified by C99.
+ if test "$pgac_need_repl_snprintf" = no; then
+   PGAC_FUNC_SNPRINTF_C99_RESULT
+   if test "$pgac_cv_snprintf_c99_result" != yes; then
+     pgac_need_repl_snprintf=yes
+   fi
+ fi
+ 
  # Now we have checked all the reasons to replace snprintf
  if test $pgac_need_repl_snprintf = yes; then
    AC_DEFINE(USE_REPL_SNPRINTF, 1, [Use replacement snprintf() functions.])
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index f458c0e..9989d3a 100644
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
*************** do_serialize(char **destptr, Size *maxby
*** 9441,9466 ****
  	if (*maxbytes <= 0)
  		elog(ERROR, "not enough space to serialize GUC state");
  
- 	errno = 0;
- 
  	va_start(vargs, fmt);
  	n = vsnprintf(*destptr, *maxbytes, fmt, vargs);
  	va_end(vargs);
  
! 	/*
! 	 * Cater to portability hazards in the vsnprintf() return value just like
! 	 * appendPQExpBufferVA() does.  Note that this requires an extra byte of
! 	 * slack at the end of the buffer.  Since serialize_variable() ends with a
! 	 * do_serialize_binary() rather than a do_serialize(), we'll always have
! 	 * that slack; estimate_variable_size() need not add a byte for it.
! 	 */
! 	if (n < 0 || n >= *maxbytes - 1)
  	{
! 		if (n < 0 && errno != 0 && errno != ENOMEM)
! 			/* Shouldn't happen. Better show errno description. */
! 			elog(ERROR, "vsnprintf failed: %m");
! 		else
! 			elog(ERROR, "not enough space to serialize GUC state");
  	}
  
  	/* Shift the destptr ahead of the null terminator */
--- 9441,9459 ----
  	if (*maxbytes <= 0)
  		elog(ERROR, "not enough space to serialize GUC state");
  
  	va_start(vargs, fmt);
  	n = vsnprintf(*destptr, *maxbytes, fmt, vargs);
  	va_end(vargs);
  
! 	if (n < 0)
  	{
! 		/* Shouldn't happen. Better show errno description. */
! 		elog(ERROR, "vsnprintf failed: %m");
! 	}
! 	if (n >= *maxbytes)
! 	{
! 		/* This shouldn't happen either, really. */
! 		elog(ERROR, "not enough space to serialize GUC state");
  	}
  
  	/* Shift the destptr ahead of the null terminator */
diff --git a/src/common/psprintf.c b/src/common/psprintf.c
index b974a99..04465a1 100644
*** a/src/common/psprintf.c
--- b/src/common/psprintf.c
*************** psprintf(const char *fmt,...)
*** 77,83 ****
   * pvsnprintf
   *
   * Attempt to format text data under the control of fmt (an sprintf-style
!  * format string) and insert it into buf (which has length len, len > 0).
   *
   * If successful, return the number of bytes emitted, not counting the
   * trailing zero byte.  This will always be strictly less than len.
--- 77,83 ----
   * pvsnprintf
   *
   * Attempt to format text data under the control of fmt (an sprintf-style
!  * format string) and insert it into buf (which has length len).
   *
   * If successful, return the number of bytes emitted, not counting the
   * trailing zero byte.  This will always be strictly less than len.
*************** psprintf(const char *fmt,...)
*** 89,102 ****
   * Other error cases do not return, but exit via elog(ERROR) or exit().
   * Hence, this shouldn't be used inside libpq.
   *
-  * This function exists mainly to centralize our workarounds for
-  * non-C99-compliant vsnprintf implementations.  Generally, any call that
-  * pays any attention to the return value should go through here rather
-  * than calling snprintf or vsnprintf directly.
-  *
   * Note that the semantics of the return value are not exactly C99's.
   * First, we don't promise that the estimated buffer size is exactly right;
   * callers must be prepared to loop multiple times to get the right size.
   * Second, we return the recommended buffer size, not one less than that;
   * this lets overflow concerns be handled here rather than in the callers.
   */
--- 89,99 ----
   * Other error cases do not return, but exit via elog(ERROR) or exit().
   * Hence, this shouldn't be used inside libpq.
   *
   * Note that the semantics of the return value are not exactly C99's.
   * First, we don't promise that the estimated buffer size is exactly right;
   * callers must be prepared to loop multiple times to get the right size.
+  * (Given a C99-compliant vsnprintf, that won't happen, but it is rumored
+  * that some implementations don't always return the same value ...)
   * Second, we return the recommended buffer size, not one less than that;
   * this lets overflow concerns be handled here rather than in the callers.
   */
*************** pvsnprintf(char *buf, size_t len, const 
*** 105,132 ****
  {
  	int			nprinted;
  
- 	Assert(len > 0);
- 
- 	errno = 0;
- 
- 	/*
- 	 * Assert check here is to catch buggy vsnprintf that overruns the
- 	 * specified buffer length.  Solaris 7 in 64-bit mode is an example of a
- 	 * platform with such a bug.
- 	 */
- #ifdef USE_ASSERT_CHECKING
- 	buf[len - 1] = '\0';
- #endif
- 
  	nprinted = vsnprintf(buf, len, fmt, args);
  
! 	Assert(buf[len - 1] == '\0');
! 
! 	/*
! 	 * If vsnprintf reports an error other than ENOMEM, fail.  The possible
! 	 * causes of this are not user-facing errors, so elog should be enough.
! 	 */
! 	if (nprinted < 0 && errno != 0 && errno != ENOMEM)
  	{
  #ifndef FRONTEND
  		elog(ERROR, "vsnprintf failed: %m");
--- 102,111 ----
  {
  	int			nprinted;
  
  	nprinted = vsnprintf(buf, len, fmt, args);
  
! 	/* We assume failure means the fmt is bogus, hence hard failure is OK */
! 	if (unlikely(nprinted < 0))
  	{
  #ifndef FRONTEND
  		elog(ERROR, "vsnprintf failed: %m");
*************** pvsnprintf(char *buf, size_t len, const 
*** 136,177 ****
  #endif
  	}
  
! 	/*
! 	 * Note: some versions of vsnprintf return the number of chars actually
! 	 * stored, not the total space needed as C99 specifies.  And at least one
! 	 * returns -1 on failure.  Be conservative about believing whether the
! 	 * print worked.
! 	 */
! 	if (nprinted >= 0 && (size_t) nprinted < len - 1)
  	{
  		/* Success.  Note nprinted does not include trailing null. */
  		return (size_t) nprinted;
  	}
  
- 	if (nprinted >= 0 && (size_t) nprinted > len)
- 	{
- 		/*
- 		 * This appears to be a C99-compliant vsnprintf, so believe its
- 		 * estimate of the required space.  (If it's wrong, the logic will
- 		 * still work, but we may loop multiple times.)  Note that the space
- 		 * needed should be only nprinted+1 bytes, but we'd better allocate
- 		 * one more than that so that the test above will succeed next time.
- 		 *
- 		 * In the corner case where the required space just barely overflows,
- 		 * fall through so that we'll error out below (possibly after
- 		 * looping).
- 		 */
- 		if ((size_t) nprinted <= MaxAllocSize - 2)
- 			return nprinted + 2;
- 	}
- 
  	/*
! 	 * Buffer overrun, and we don't know how much space is needed.  Estimate
! 	 * twice the previous buffer size, but not more than MaxAllocSize; if we
! 	 * are already at MaxAllocSize, choke.  Note we use this palloc-oriented
! 	 * overflow limit even when in frontend.
  	 */
! 	if (len >= MaxAllocSize)
  	{
  #ifndef FRONTEND
  		ereport(ERROR,
--- 115,135 ----
  #endif
  	}
  
! 	if ((size_t) nprinted < len)
  	{
  		/* Success.  Note nprinted does not include trailing null. */
  		return (size_t) nprinted;
  	}
  
  	/*
! 	 * We assume a C99-compliant vsnprintf, so believe its estimate of the
! 	 * required space, and add one for the trailing null.  (If it's wrong, the
! 	 * logic will still work, but we may loop multiple times.)
! 	 *
! 	 * Choke if the required space would exceed MaxAllocSize.  Note we use
! 	 * this palloc-oriented overflow limit even when in frontend.
  	 */
! 	if (unlikely((size_t) nprinted > MaxAllocSize - 1))
  	{
  #ifndef FRONTEND
  		ereport(ERROR,
*************** pvsnprintf(char *buf, size_t len, const 
*** 183,190 ****
  #endif
  	}
  
! 	if (len >= MaxAllocSize / 2)
! 		return MaxAllocSize;
! 
! 	return len * 2;
  }
--- 141,145 ----
  #endif
  	}
  
! 	return nprinted + 1;
  }
diff --git a/src/interfaces/libpq/pqexpbuffer.c b/src/interfaces/libpq/pqexpbuffer.c
index 86b16e6..0814ec6 100644
*** a/src/interfaces/libpq/pqexpbuffer.c
--- b/src/interfaces/libpq/pqexpbuffer.c
*************** appendPQExpBufferVA(PQExpBuffer str, con
*** 295,370 ****
  	 */
  	if (str->maxlen > str->len + 16)
  	{
! 		/*
! 		 * Note: we intentionally leave one byte unused, as a guard against
! 		 * old broken versions of vsnprintf.
! 		 */
! 		avail = str->maxlen - str->len - 1;
! 
! 		errno = 0;
  
  		nprinted = vsnprintf(str->data + str->len, avail, fmt, args);
  
  		/*
! 		 * If vsnprintf reports an error other than ENOMEM, fail.
  		 */
! 		if (nprinted < 0 && errno != 0 && errno != ENOMEM)
  		{
  			markPQExpBufferBroken(str);
  			return true;
  		}
  
! 		/*
! 		 * Note: some versions of vsnprintf return the number of chars
! 		 * actually stored, not the total space needed as C99 specifies.  And
! 		 * at least one returns -1 on failure.  Be conservative about
! 		 * believing whether the print worked.
! 		 */
! 		if (nprinted >= 0 && (size_t) nprinted < avail - 1)
  		{
  			/* Success.  Note nprinted does not include trailing null. */
  			str->len += nprinted;
  			return true;
  		}
  
! 		if (nprinted >= 0 && (size_t) nprinted > avail)
! 		{
! 			/*
! 			 * This appears to be a C99-compliant vsnprintf, so believe its
! 			 * estimate of the required space. (If it's wrong, the logic will
! 			 * still work, but we may loop multiple times.)  Note that the
! 			 * space needed should be only nprinted+1 bytes, but we'd better
! 			 * allocate one more than that so that the test above will succeed
! 			 * next time.
! 			 *
! 			 * In the corner case where the required space just barely
! 			 * overflows, fail.
! 			 */
! 			if (nprinted > INT_MAX - 2)
! 			{
! 				markPQExpBufferBroken(str);
! 				return true;
! 			}
! 			needed = nprinted + 2;
! 		}
! 		else
  		{
! 			/*
! 			 * Buffer overrun, and we don't know how much space is needed.
! 			 * Estimate twice the previous buffer size, but not more than
! 			 * INT_MAX.
! 			 */
! 			if (avail >= INT_MAX / 2)
! 				needed = INT_MAX;
! 			else
! 				needed = avail * 2;
  		}
  	}
  	else
  	{
  		/*
  		 * We have to guess at how much to enlarge, since we're skipping the
! 		 * formatting work.
  		 */
  		needed = 32;
  	}
--- 295,344 ----
  	 */
  	if (str->maxlen > str->len + 16)
  	{
! 		avail = str->maxlen - str->len;
  
  		nprinted = vsnprintf(str->data + str->len, avail, fmt, args);
  
  		/*
! 		 * If vsnprintf reports an error, fail (we assume this means there's
! 		 * something wrong with the format string).
  		 */
! 		if (unlikely(nprinted < 0))
  		{
  			markPQExpBufferBroken(str);
  			return true;
  		}
  
! 		if ((size_t) nprinted < avail)
  		{
  			/* Success.  Note nprinted does not include trailing null. */
  			str->len += nprinted;
  			return true;
  		}
  
! 		/*
! 		 * We assume a C99-compliant vsnprintf, so believe its estimate of the
! 		 * required space, and add one for the trailing null.  (If it's wrong,
! 		 * the logic will still work, but we may loop multiple times.)
! 		 *
! 		 * Choke if the required space would exceed INT_MAX, since str->maxlen
! 		 * can't represent more than that.
! 		 */
! 		if (unlikely(nprinted > INT_MAX - 1))
  		{
! 			markPQExpBufferBroken(str);
! 			return true;
  		}
+ 		needed = nprinted + 1;
  	}
  	else
  	{
  		/*
  		 * We have to guess at how much to enlarge, since we're skipping the
! 		 * formatting work.  Fortunately, because of enlargePQExpBuffer's
! 		 * preference for power-of-2 sizes, this number isn't very sensitive;
! 		 * the net effect is that we'll double the buffer size before trying
! 		 * to run vsnprintf, which seems sensible.
  		 */
  		needed = 32;
  	}
#30Thomas Munro
thomas.munro@enterprisedb.com
In reply to: Andres Freund (#28)
Re: C99 compliance for src/port/snprintf.c

On Thu, Aug 16, 2018 at 11:06 AM, Andres Freund <andres@anarazel.de> wrote:

On 2018-08-16 10:54:01 +1200, Thomas Munro wrote:

Really? I am not an MSVC user but I had the impression that their C
mode (/TC or files named .c) was stuck on C89/C90 as a matter of
policy, as Herb Sutter explained here (though maybe the situation has
changed since then):

They revised their position gradually, starting soon after. They claim
full C99 "language" (vs library, which is also pretty complete)
compliance now. I've not yet bothered to fully figure out which version
supports what however. Nor am I really sure about the whole flag thing,
it appears there's a gui element to choose, which we might need to mirror on
the xml level.

Hah, I see. Thanks apparently due to FFmpeg for helping them change
their minds. That seems like a bit of a catch-22 for projects that
care about portability. (Maybe if we start writing C11 they'll change
the compiler to keep up? Actually I already did that once, with an
anonymous union that turned the build farm slightly red...)

https://stackoverflow.com/questions/27826409/what-is-the-official-status-of-c99-support-in-vs2013

...
which I think is what we roughly would want. So it looks like msvc 2013
might be the relevant requirement.

FWIW cfbot is using Visual Studio 2010 right now. Appveyor provides
2008, 2010, 2012, 2013 (AKA 12.0), 2015, 2017, and to test with a
different toolchain you can take the example patch from
https://wiki.postgresql.org/wiki/Continuous_Integration and add a line
like this to the end of the install section (worked for me; for 2015+
you probably also need to request a different image):

- 'call "C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat" x86_amd64'

I'll make that change to cfbot if we decree that it is the new
baseline for PostgreSQL on Windows. Or I could do it sooner if anyone
wants to be able to post test C99 patches in the Commitfest before we
decide.

--
Thomas Munro
http://www.enterprisedb.com

#31Nico Williams
nico@cryptonector.com
In reply to: Thomas Munro (#30)
Re: C99 compliance for src/port/snprintf.c

There's also clang on Windows, which VS apparently supports. With clang
on Windows PG could even make use of GCC/Clang C extensions :^)

#32Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#24)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-15 18:31:10 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

I think we could get a start by adding that test to configure, without
relying on it for now (i.e. keeping mylodon with -Wc99-extensions
-Werror=c99-extensions alive). That'd tell us about which machines,
besides presumably gaur, we'd need to either kick to the curb or change.

Sure, no objection to putting that in just to see how much of the
buildfarm can handle it. If the answer turns out to be "a lot",
we might have to reconsider, but gathering data seems like the
first thing to do.

I've pushed a minimal version adding the C99 test. If we were to
actually go for this permanently, we'd likely want to clean up a bunch
of other tests (say removing PGAC_C_VA_ARGS), but I don't see much point
in doing that while just gathering evidence (to the contrary, it seems
like it'd just muddy the water a bit).

Greetings,

Andres Freund

#33Andres Freund
andres@anarazel.de
In reply to: Andres Freund (#32)
Re: C99 compliance for src/port/snprintf.c

On 2018-08-16 01:41:34 -0700, Andres Freund wrote:

I've pushed a minimal version adding the C99 test.

So, we get:

* lotsa animals, unsurprisingly, showing C99 work without any flags.

checking for ccache gcc option to accept ISO C99... none needed

* rhinoceros, nudibranch, grouse, ...:

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rhinoceros&amp;dt=2018-08-16%2008%3A45%3A01&amp;stg=configure
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=nudibranch&amp;dt=2018-08-16%2009%3A16%3A46&amp;stg=configure
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=grouse&amp;dt=2018-08-16%2009%3A17%3A25&amp;stg=configure
checking for ccache gcc option to accept ISO C99... -std=gnu99 (or variations thereof)

So, the autoconf magic is doing it's thing here.

* dunlin (icc):

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=dunlin&amp;dt=2018-08-16%2009%3A35%3A19&amp;stg=configure
checking for icc option to accept ISO C99... -std=gnu99

(later fails, but not newly so, and just because of ENOSPC)

* anole (HP C compiler)

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=anole&amp;dt=2018-08-16 09%3A32%3A19
checking for cc option to accept ISO C99... none needed

* dromedary:

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=dromedary&amp;dt=2018-08-16%2008%3A37%3A28&amp;stg=configure
checking for ccache gcc option to accept ISO C99... unsupported

I suspect that's because of the '-ansi' flag in CFLAGS, not because
the compiler is incapable of actually supporting C99.

Besides gaur, I'm also awaiting casteroides' results. The latter
definitely does support C99, but I'm not sure autconf pushes hard
enough. I think every other relevant animal has reported back.

Greetings,

Andres Freund

#34Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Andres Freund (#33)
Re: C99 compliance for src/port/snprintf.c

On 16/08/2018 13:18, Andres Freund wrote:

checking for ccache gcc option to accept ISO C99... unsupported

I suspect that's because of the '-ansi' flag in CFLAGS, not because
the compiler is incapable of actually supporting C99.

-ansi is equivalent to -std=c90. If we make the switch, the build farm
configuration should just probably replace -ansi with -std=c99.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#35Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Andres Freund (#28)
Re: C99 compliance for src/port/snprintf.c

On 16/08/2018 01:06, Andres Freund wrote:

So it looks like msvc 2013 might be the relevant requirement.

According to my research (completely untested in practice), you need
2010 for mixed code and declarations and 2013 for named initialization
of structs.

I wonder what raising the msvc requirement would imply for supporting
older Windows versions.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#36Andres Freund
andres@anarazel.de
In reply to: Peter Eisentraut (#34)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-16 14:26:07 +0200, Peter Eisentraut wrote:

On 16/08/2018 13:18, Andres Freund wrote:

checking for ccache gcc option to accept ISO C99... unsupported

I suspect that's because of the '-ansi' flag in CFLAGS, not because
the compiler is incapable of actually supporting C99.

-ansi is equivalent to -std=c90. If we make the switch, the build farm
configuration should just probably replace -ansi with -std=c99.

Right. I just hadn't checked the addition of -std=c99 doesn't override
the -ansi. Presumably just an ordering thing.

Greetings,

Andres Freund

#37Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Andres Freund (#36)
Re: C99 compliance for src/port/snprintf.c

On 16/08/2018 14:30, Andres Freund wrote:

Hi,

On 2018-08-16 14:26:07 +0200, Peter Eisentraut wrote:

On 16/08/2018 13:18, Andres Freund wrote:

checking for ccache gcc option to accept ISO C99... unsupported

I suspect that's because of the '-ansi' flag in CFLAGS, not because
the compiler is incapable of actually supporting C99.

-ansi is equivalent to -std=c90. If we make the switch, the build farm
configuration should just probably replace -ansi with -std=c99.

Right. I just hadn't checked the addition of -std=c99 doesn't override
the -ansi. Presumably just an ordering thing.

The mistake is putting -ansi or similar options into CFLAGS. You need
to put them into CC.

The Autoconf test for C99 correctly puts the candidate options into CC,
but then if the test compilation invocation is something like "$CC
$CFLAGS -c conftest.c", the -ansi cancels out the earlier -std=c99 or
whatever.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#38Andres Freund
andres@anarazel.de
In reply to: Peter Eisentraut (#35)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-16 14:28:25 +0200, Peter Eisentraut wrote:

On 16/08/2018 01:06, Andres Freund wrote:

So it looks like msvc 2013 might be the relevant requirement.

According to my research (completely untested in practice), you need
2010 for mixed code and declarations and 2013 for named initialization
of structs.

I wonder what raising the msvc requirement would imply for supporting
older Windows versions.

One relevant tidbit is that afaict 2013 still allows *targeting* older
versions of windows, down to XP and 2003, while requiring a newer
platforms to run. See:
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-compatibility-vs
I don't know if that's hard to do, but I strongly suspect that the
existing installers already do that (otherwise supporting newer versions
would likely require separate builds).

2013 still runs on Windows 7, should you want that:
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs

According to https://www.postgresql.org/download/windows/
the available binaries already effectively restrict windows support:

EDB installers, for 10, restrict to:
64 Bit Windows: 2016, 2012 R2 & R1, 2008 R2, 7, 8, 10
32 Bit Windows: 2008 R1, 7, 8, 10

BIGSQL to: Windows 10 and Windows Server 2012.

Of those 2013 only doesn't run on 2008 R1 anymore. Which still can be
targeted from the newer windows versions.

It'd be good to get confirmation that the windows binaries / installers
are indeed built on newer platforms than the oldest supported version.

Random observation: http://www.openscg.com/bigsql/postgresql/installers/
seems to indicate that packages aren't updated anymore. While it says
"(09-Aug-18)" besides the major versions, it does not actually in fact
have the last set of minor releases. I suspect that's related to
openscg's acquisition by amazon? Either they need to catch up, or we
need to take down the page and probably alert people about that fact.

Greetings,

Andres Freund

#39Andres Freund
andres@anarazel.de
In reply to: Andres Freund (#33)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-16 04:18:59 -0700, Andres Freund wrote:

Besides gaur, I'm also awaiting casteroides' results. The latter
definitely does support C99, but I'm not sure autconf pushes hard
enough. I think every other relevant animal has reported back.

Casteroides wasn't a problem, -D_STDC_C99= does the trick.

But enabling C99 support triggered a somewhat weird failure on
protosciurus (also solaris, but gcc)
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&amp;dt=2018-08-16%2013%3A37%3A46

It detects C99 support successfully via -std=gnu99 but then fails
somewhere during build with:

gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -g -I/usr/local/include -m64 -I../../../../src/include -c -o gistutil.o gistutil.c
In file included from gistutil.c:24:
../../../../src/include/utils/float.h: In function `get_float4_infinity':
../../../../src/include/utils/float.h:71: error: `__builtin_infinity' undeclared (first use in this function)
../../../../src/include/utils/float.h:71: error: (Each undeclared identifier is reported only once
../../../../src/include/utils/float.h:71: error: for each function it appears in.)
../../../../src/include/utils/float.h: In function `get_float8_infinity':
../../../../src/include/utils/float.h:91: error: `__builtin_infinity' undeclared (first use in this function)
../../../../src/include/utils/float.h: In function `get_float4_nan':
../../../../src/include/utils/float.h:108: error: pointer value used where a floating point value was expected
../../../../src/include/utils/float.h: In function `get_float8_nan':
../../../../src/include/utils/float.h:121: error: pointer value used where a floating point value was expected
../../../../src/include/utils/float.h: In function `check_float4_val':
../../../../src/include/utils/float.h:136: warning: implicit declaration of function `__builtin_isinf'
../../../../src/include/utils/float.h: In function `float4_eq':
../../../../src/include/utils/float.h:283: warning: implicit declaration of function `__builtin_isnan'

While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
still confused what causes this error mode. Kinda looks like
out-of-sync headers with gcc or something.

Greetings,

Andres Freund

#40Bruce Momjian
bruce@momjian.us
In reply to: Andres Freund (#38)
Problem with OpenSCG downloads

On Thu, Aug 16, 2018 at 06:00:30AM -0700, Andres Freund wrote:

Random observation: http://www.openscg.com/bigsql/postgresql/installers/
seems to indicate that packages aren't updated anymore. While it says
"(09-Aug-18)" besides the major versions, it does not actually in fact
have the last set of minor releases. I suspect that's related to
openscg's acquisition by amazon? Either they need to catch up, or we
need to take down the page and probably alert people about that fact.

Forwarding Andres's email above to www for research.

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

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
#41Dave Page
dpage@pgadmin.org
In reply to: Bruce Momjian (#40)
Re: Problem with OpenSCG downloads

On Thu, Aug 16, 2018 at 3:35 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Thu, Aug 16, 2018 at 06:00:30AM -0700, Andres Freund wrote:

Random observation: http://www.openscg.com/bigsql/postgresql/installers/
seems to indicate that packages aren't updated anymore. While it says
"(09-Aug-18)" besides the major versions, it does not actually in fact
have the last set of minor releases. I suspect that's related to
openscg's acquisition by amazon? Either they need to catch up, or we
need to take down the page and probably alert people about that fact.

Forwarding Andres's email above to www for research.

Jimbo assured me at PGCon that Amazon were going to ensure those packages
were kept up to date in the normal schedule.

Jim, do you know what's happening?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#42Jim Mlodgenski
jimm@postgresconf.org
In reply to: Dave Page (#41)
Re: Problem with OpenSCG downloads

On Thu, Aug 16, 2018 at 11:00 AM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Aug 16, 2018 at 3:35 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Thu, Aug 16, 2018 at 06:00:30AM -0700, Andres Freund wrote:

Random observation: http://www.openscg.com/bigsql/

postgresql/installers/

seems to indicate that packages aren't updated anymore. While it says
"(09-Aug-18)" besides the major versions, it does not actually in fact
have the last set of minor releases. I suspect that's related to
openscg's acquisition by amazon? Either they need to catch up, or we
need to take down the page and probably alert people about that fact.

Forwarding Andres's email above to www for research.

Jimbo assured me at PGCon that Amazon were going to ensure those packages
were kept up to date in the normal schedule.

Jim, do you know what's happening?

Yea, we are working on getting them out ASAP. Because of the acquisition,
our build servers are now sitting in physical locations where people don't
regularly work. In this particular case, they are sitting in our NJ office
which had a power outage long enough the the UPS drained requiring someone
to physically hit the button to power up the servers so we can do the
builds. We're working on moving the builds to this newfangled thing called
the cloud so we don't have the problem in the future. :-)

I'll ask the team to give me an ETA and report back.

#43Dave Page
dpage@pgadmin.org
In reply to: Jim Mlodgenski (#42)
Re: Problem with OpenSCG downloads

On Thu, Aug 16, 2018 at 4:19 PM, Jim Mlodgenski <jimm@postgresconf.org>
wrote:

On Thu, Aug 16, 2018 at 11:00 AM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Aug 16, 2018 at 3:35 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Thu, Aug 16, 2018 at 06:00:30AM -0700, Andres Freund wrote:

Random observation: http://www.openscg.com/bigsql/

postgresql/installers/

seems to indicate that packages aren't updated anymore. While it says
"(09-Aug-18)" besides the major versions, it does not actually in fact
have the last set of minor releases. I suspect that's related to
openscg's acquisition by amazon? Either they need to catch up, or we
need to take down the page and probably alert people about that fact.

Forwarding Andres's email above to www for research.

Jimbo assured me at PGCon that Amazon were going to ensure those packages
were kept up to date in the normal schedule.

Jim, do you know what's happening?

Yea, we are working on getting them out ASAP. Because of the acquisition,
our build servers are now sitting in physical locations where people don't
regularly work. In this particular case, they are sitting in our NJ office
which had a power outage long enough the the UPS drained requiring someone
to physically hit the button to power up the servers so we can do the
builds. We're working on moving the builds to this newfangled thing called
the cloud so we don't have the problem in the future. :-)

I'll ask the team to give me an ETA and report back.

Thanks Jim.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#44Andres Freund
andres@anarazel.de
In reply to: Jim Mlodgenski (#42)
Re: Problem with OpenSCG downloads

Hi,

On 2018-08-16 11:19:49 -0400, Jim Mlodgenski wrote:

On Thu, Aug 16, 2018 at 11:00 AM, Dave Page <dpage@pgadmin.org> wrote:

Jimbo assured me at PGCon that Amazon were going to ensure those packages
were kept up to date in the normal schedule.

Jim, do you know what's happening?

Yea, we are working on getting them out ASAP. Because of the acquisition,
our build servers are now sitting in physical locations where people don't
regularly work. In this particular case, they are sitting in our NJ office
which had a power outage long enough the the UPS drained requiring someone
to physically hit the button to power up the servers so we can do the
builds. We're working on moving the builds to this newfangled thing called
the cloud so we don't have the problem in the future. :-)

I'll ask the team to give me an ETA and report back.

FWIW, I find this pretty damning given that there's been new security
release for a week: You've added no notes about it to the bigsql
download page. Pinged nobody, to get the downloadlinks temporarily
adorned with a warning on the pg site. And then there's the issue that
the dates besides the releases on the download page are referencing the
date of the newest set of minor releases, but aren't actually new.

This is ridiculously intransparent.

Greetings,

Andres Freund

#45Justin Clift
justin@postgresql.org
In reply to: Andres Freund (#44)
Re: Problem with OpenSCG downloads

On 2018-08-16 16:25, Andres Freund wrote:

Hi,

On 2018-08-16 11:19:49 -0400, Jim Mlodgenski wrote:

On Thu, Aug 16, 2018 at 11:00 AM, Dave Page <dpage@pgadmin.org> wrote:

Jimbo assured me at PGCon that Amazon were going to ensure those packages
were kept up to date in the normal schedule.

Jim, do you know what's happening?

Yea, we are working on getting them out ASAP. Because of the
acquisition,
our build servers are now sitting in physical locations where people
don't
regularly work. In this particular case, they are sitting in our NJ
office
which had a power outage long enough the the UPS drained requiring
someone
to physically hit the button to power up the servers so we can do the
builds. We're working on moving the builds to this newfangled thing
called
the cloud so we don't have the problem in the future. :-)

I'll ask the team to give me an ETA and report back.

FWIW, I find this pretty damning given that there's been new security
release for a week: You've added no notes about it to the bigsql
download page. Pinged nobody, to get the downloadlinks temporarily
adorned with a warning on the pg site. And then there's the issue that
the dates besides the releases on the download page are referencing the
date of the newest set of minor releases, but aren't actually new.

This is ridiculously intransparent.

Is it fairly simple for us to just comment out/remove the links for now?

We don't want to be pointing people to software with known security
issues.

We can put the links back in when the updated downloads are in place. :)

+ Justin

#46Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#39)
Re: C99 compliance for src/port/snprintf.c

Andres Freund <andres@anarazel.de> writes:

But enabling C99 support triggered a somewhat weird failure on
protosciurus (also solaris, but gcc)
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&amp;dt=2018-08-16%2013%3A37%3A46

It detects C99 support successfully via -std=gnu99 but then fails
somewhere during build with:
../../../../src/include/utils/float.h:71: error: `__builtin_infinity' undeclared (first use in this function)

While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
still confused what causes this error mode. Kinda looks like
out-of-sync headers with gcc or something.

Yeah, this is *absolutely* unsurprising for a non-native gcc installation
on an old platform. It only works to the extent that the platform's
library headers are up to snuff. The gcc installation process actually
knows enough to do a certain amount of editing of the platform's headers,
and install "fixed" copies of those headers where gcc will find them
before the ones in /usr/include. But it looks like the fixing didn't
account for __builtin_infinity on this platform. Maybe a newer gcc
would get it right.

I just launched gaur/pademelon builds for you, though I'm quite certain
they'll both report "unsupported". If we go through with this, my plan
would be to retire pademelon (vendor's compiler) and see if I can install
gcc 4.something to replace the 2.95.3 version that gaur is using. The
-ansi option that dromedary is using is certainly losable, too (I'd
probably replace it with either --std=c99 or --std=gnu99, whichever
autoconf *doesn't* pick by default, just to be contrary).

Andrew is going to need to give us a policy decision on whether to
keep using the existing animal names or take out new ones for these
rather-significantly-modified configurations.

regards, tom lane

#47Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#46)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-16 11:41:30 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

But enabling C99 support triggered a somewhat weird failure on
protosciurus (also solaris, but gcc)
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&amp;dt=2018-08-16%2013%3A37%3A46

It detects C99 support successfully via -std=gnu99 but then fails
somewhere during build with:
../../../../src/include/utils/float.h:71: error: `__builtin_infinity' undeclared (first use in this function)

While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
still confused what causes this error mode. Kinda looks like
out-of-sync headers with gcc or something.

Yeah, this is *absolutely* unsurprising for a non-native gcc installation
on an old platform. It only works to the extent that the platform's
library headers are up to snuff. The gcc installation process actually
knows enough to do a certain amount of editing of the platform's headers,
and install "fixed" copies of those headers where gcc will find them
before the ones in /usr/include. But it looks like the fixing didn't
account for __builtin_infinity on this platform. Maybe a newer gcc
would get it right.

Sure, but that still requires the headers to behave differently between
C89 and C99 mode, as this worked before. But it turns out there's two
different math.h implementation headers, depending on c99 being enabled
(math_c99.h being the troublesome). If I understand correctly the
problem is more that the system library headers are *newer* (and assume
a sun studio emulating/copying quite a bit of gcc) than the gcc that's
being used, and therefore gcc fails.

Gcc 3.4.3 has been released November 4, 2004, whereas solaris 10 is from
January 31, 2005. The sun studio used for castoroides running on, I
assume, the same hardware, is quite a bit newer in turn.

I just launched gaur/pademelon builds for you, though I'm quite certain
they'll both report "unsupported".

Yea, that seems fairly likely.

If we go through with this, my plan would be to retire pademelon
(vendor's compiler) and see if I can install gcc 4.something to
replace the 2.95.3 version that gaur is using.

K.

The -ansi option that dromedary is using is certainly losable, too
(I'd probably replace it with either --std=c99 or --std=gnu99,
whichever autoconf *doesn't* pick by default, just to be contrary).

Makes sense.

Andrew is going to need to give us a policy decision on whether to
keep using the existing animal names or take out new ones for these
rather-significantly-modified configurations.

CCed.

Greetings,

Andres Freund

#48Andres Freund
andres@anarazel.de
In reply to: Justin Clift (#45)
Re: Problem with OpenSCG downloads

On 2018-08-16 16:32:00 +0100, Justin Clift wrote:

On 2018-08-16 16:25, Andres Freund wrote:

FWIW, I find this pretty damning given that there's been new security
release for a week: You've added no notes about it to the bigsql
download page. Pinged nobody, to get the downloadlinks temporarily
adorned with a warning on the pg site. And then there's the issue that
the dates besides the releases on the download page are referencing the
date of the newest set of minor releases, but aren't actually new.

This is ridiculously intransparent.

Is it fairly simple for us to just comment out/remove the links for now?

We don't want to be pointing people to software with known security issues.

We can put the links back in when the updated downloads are in place. :)

Probably don't want to remove them entirely, it might prevent people
from upgrading from an even older release with more serious issues. But
a red warning seems appropriate.

Greetings,

Andres Freund

#49Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Andres Freund (#47)
Re: C99 compliance for src/port/snprintf.c

On 08/16/2018 12:05 PM, Andres Freund wrote:

Hi,

On 2018-08-16 11:41:30 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

But enabling C99 support triggered a somewhat weird failure on
protosciurus (also solaris, but gcc)
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&amp;dt=2018-08-16%2013%3A37%3A46
It detects C99 support successfully via -std=gnu99 but then fails
somewhere during build with:
../../../../src/include/utils/float.h:71: error: `__builtin_infinity' undeclared (first use in this function)
While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
still confused what causes this error mode. Kinda looks like
out-of-sync headers with gcc or something.

Yeah, this is *absolutely* unsurprising for a non-native gcc installation
on an old platform. It only works to the extent that the platform's
library headers are up to snuff. The gcc installation process actually
knows enough to do a certain amount of editing of the platform's headers,
and install "fixed" copies of those headers where gcc will find them
before the ones in /usr/include. But it looks like the fixing didn't
account for __builtin_infinity on this platform. Maybe a newer gcc
would get it right.

Sure, but that still requires the headers to behave differently between
C89 and C99 mode, as this worked before. But it turns out there's two
different math.h implementation headers, depending on c99 being enabled
(math_c99.h being the troublesome). If I understand correctly the
problem is more that the system library headers are *newer* (and assume
a sun studio emulating/copying quite a bit of gcc) than the gcc that's
being used, and therefore gcc fails.

Gcc 3.4.3 has been released November 4, 2004, whereas solaris 10 is from
January 31, 2005. The sun studio used for castoroides running on, I
assume, the same hardware, is quite a bit newer in turn.

I just launched gaur/pademelon builds for you, though I'm quite certain
they'll both report "unsupported".

Yea, that seems fairly likely.

If we go through with this, my plan would be to retire pademelon
(vendor's compiler) and see if I can install gcc 4.something to
replace the 2.95.3 version that gaur is using.

K.

The -ansi option that dromedary is using is certainly losable, too
(I'd probably replace it with either --std=c99 or --std=gnu99,
whichever autoconf *doesn't* pick by default, just to be contrary).

Makes sense.

Andrew is going to need to give us a policy decision on whether to
keep using the existing animal names or take out new ones for these
rather-significantly-modified configurations.

CCed.

The usual policy is that animal names need to change if the OS or
compiler names change, but not if just the versions of those change.
There is a script in the suite to update those settings, and the admins
can also help if necessary.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#50Bruce Momjian
bruce@momjian.us
In reply to: Andres Freund (#48)
Re: Problem with OpenSCG downloads

On Thu, Aug 16, 2018 at 09:25:36AM -0700, Andres Freund wrote:

On 2018-08-16 16:32:00 +0100, Justin Clift wrote:

On 2018-08-16 16:25, Andres Freund wrote:

FWIW, I find this pretty damning given that there's been new security
release for a week: You've added no notes about it to the bigsql
download page. Pinged nobody, to get the downloadlinks temporarily
adorned with a warning on the pg site. And then there's the issue that
the dates besides the releases on the download page are referencing the
date of the newest set of minor releases, but aren't actually new.

This is ridiculously intransparent.

Is it fairly simple for us to just comment out/remove the links for now?

We don't want to be pointing people to software with known security issues.

We can put the links back in when the updated downloads are in place. :)

Probably don't want to remove them entirely, it might prevent people
from upgrading from an even older release with more serious issues. But
a red warning seems appropriate.

Agreed. We need to do something _now_, and the fact that we are having
to discover this instead of OpenSCG telling us is a good reason to
suspect the use of this download site in the future.

Looking at their website now, does it show they now have the proper
binaries?

https://www.openscg.com/bigsql/postgresql/installers/

PostgreSQL 10.5 - Stable (09-Aug-18)

postgresql-10.5-win64.exe
postgresql-10.5-osx64.dmg

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

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
#51Magnus Hagander
magnus@hagander.net
In reply to: Bruce Momjian (#50)
Re: Problem with OpenSCG downloads

On Fri, Aug 17, 2018 at 4:39 AM, Bruce Momjian <bruce@momjian.us> wrote:

On Thu, Aug 16, 2018 at 09:25:36AM -0700, Andres Freund wrote:

On 2018-08-16 16:32:00 +0100, Justin Clift wrote:

On 2018-08-16 16:25, Andres Freund wrote:

FWIW, I find this pretty damning given that there's been new security
release for a week: You've added no notes about it to the bigsql
download page. Pinged nobody, to get the downloadlinks temporarily
adorned with a warning on the pg site. And then there's the issue

that

the dates besides the releases on the download page are referencing

the

date of the newest set of minor releases, but aren't actually new.

This is ridiculously intransparent.

Is it fairly simple for us to just comment out/remove the links for

now?

We don't want to be pointing people to software with known security

issues.

We can put the links back in when the updated downloads are in place.

:)

Probably don't want to remove them entirely, it might prevent people
from upgrading from an even older release with more serious issues. But
a red warning seems appropriate.

Agreed. We need to do something _now_, and the fact that we are having
to discover this instead of OpenSCG telling us is a good reason to
suspect the use of this download site in the future.

Looking at their website now, does it show they now have the proper
binaries?

https://www.openscg.com/bigsql/postgresql/installers/

PostgreSQL 10.5 - Stable (09-Aug-18)

postgresql-10.5-win64.exe
postgresql-10.5-osx64.dmg

Per the filenames it looks like they do. But the dates are still backdated
on them?

Jim, any confirmation on the status?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

#52Bruce Momjian
bruce@momjian.us
In reply to: Magnus Hagander (#51)
Re: Problem with OpenSCG downloads

On Fri, Aug 17, 2018 at 09:48:26AM +0200, Magnus Hagander wrote:

Looking at their website now, does it show they now have the proper
binaries?

� � � � https://www.openscg.com/bigsql/postgresql/installers/

� � � � PostgreSQL 10.5 - Stable� (09-Aug-18)

� � � � � � postgresql-10.5-win64.exe
� � � � � � postgresql-10.5-osx64.dmg

Per the filenames it looks like they do. But the dates are still backdated on
them?

Uh, what's the matter with the dates now? 2018-08-09 is the release
date of 10.5.

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

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +
#53Jim Mlodgenski
jimmy76@gmail.com
In reply to: Magnus Hagander (#51)
Re: Problem with OpenSCG downloads

On Fri, Aug 17, 2018 at 3:48 AM, Magnus Hagander <magnus@hagander.net>
wrote:

On Fri, Aug 17, 2018 at 4:39 AM, Bruce Momjian <bruce@momjian.us> wrote:

On Thu, Aug 16, 2018 at 09:25:36AM -0700, Andres Freund wrote:

On 2018-08-16 16:32:00 +0100, Justin Clift wrote:

On 2018-08-16 16:25, Andres Freund wrote:

FWIW, I find this pretty damning given that there's been new

security

release for a week: You've added no notes about it to the bigsql
download page. Pinged nobody, to get the downloadlinks temporarily
adorned with a warning on the pg site. And then there's the issue

that

the dates besides the releases on the download page are referencing

the

date of the newest set of minor releases, but aren't actually new.

This is ridiculously intransparent.

Is it fairly simple for us to just comment out/remove the links for

now?

We don't want to be pointing people to software with known security

issues.

We can put the links back in when the updated downloads are in place.

:)

Probably don't want to remove them entirely, it might prevent people
from upgrading from an even older release with more serious issues. But
a red warning seems appropriate.

Agreed. We need to do something _now_, and the fact that we are having
to discover this instead of OpenSCG telling us is a good reason to
suspect the use of this download site in the future.

Looking at their website now, does it show they now have the proper
binaries?

https://www.openscg.com/bigsql/postgresql/installers/

PostgreSQL 10.5 - Stable (09-Aug-18)

postgresql-10.5-win64.exe
postgresql-10.5-osx64.dmg

Per the filenames it looks like they do. But the dates are still backdated
on them?

Jim, any confirmation on the status?

Yes, we pushed the latest installers last night.

The reason for the back date is because we did post new binaries on Aug-9,
but didn't post the new installers until last night. That meant that
existing users of the installers would get the latest updates posted on
Aug-9 if they checked for updates through the mechanism of their existing
install. Also, if new users installed the older version, at the end they
would see there are updates available if they checked. The server we used
to wrap the installers was down which caused the delay.

Sorry for the trouble and we'll be much more proactive of letting everyone
know if we have any difficulty in the future which I don't anticipate
happening.

#54Magnus Hagander
magnus@hagander.net
In reply to: Jim Mlodgenski (#53)
Re: Problem with OpenSCG downloads

On Fri, Aug 17, 2018 at 2:35 PM, Jim Mlodgenski <jimmy76@gmail.com> wrote:

On Fri, Aug 17, 2018 at 3:48 AM, Magnus Hagander <magnus@hagander.net>
wrote:

On Fri, Aug 17, 2018 at 4:39 AM, Bruce Momjian <bruce@momjian.us> wrote:

On Thu, Aug 16, 2018 at 09:25:36AM -0700, Andres Freund wrote:

On 2018-08-16 16:32:00 +0100, Justin Clift wrote:

On 2018-08-16 16:25, Andres Freund wrote:

FWIW, I find this pretty damning given that there's been new

security

release for a week: You've added no notes about it to the bigsql
download page. Pinged nobody, to get the downloadlinks temporarily
adorned with a warning on the pg site. And then there's the issue

that

the dates besides the releases on the download page are

referencing the

date of the newest set of minor releases, but aren't actually new.

This is ridiculously intransparent.

Is it fairly simple for us to just comment out/remove the links for

now?

We don't want to be pointing people to software with known security

issues.

We can put the links back in when the updated downloads are in

place. :)

Probably don't want to remove them entirely, it might prevent people
from upgrading from an even older release with more serious issues. But
a red warning seems appropriate.

Agreed. We need to do something _now_, and the fact that we are having
to discover this instead of OpenSCG telling us is a good reason to
suspect the use of this download site in the future.

Looking at their website now, does it show they now have the proper
binaries?

https://www.openscg.com/bigsql/postgresql/installers/

PostgreSQL 10.5 - Stable (09-Aug-18)

postgresql-10.5-win64.exe
postgresql-10.5-osx64.dmg

Per the filenames it looks like they do. But the dates are still
backdated on them?

Jim, any confirmation on the status?

Yes, we pushed the latest installers last night.

Great, thanks for confirming!

The reason for the back date is because we did post new binaries on Aug-9,

but didn't post the new installers until last night. That meant that
existing users of the installers would get the latest updates posted on
Aug-9 if they checked for updates through the mechanism of their existing
install. Also, if new users installed the older version, at the end they
would see there are updates available if they checked. The server we used
to wrap the installers was down which caused the delay.

Ah, gotcha. That explains it.

Sorry for the trouble and we'll be much more proactive of letting everyone

know if we have any difficulty in the future which I don't anticipate
happening.

Thanks!

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

#55Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Andres Freund (#38)
1 attachment(s)
Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 16/08/2018 15:00, Andres Freund wrote:

According to my research (completely untested in practice), you need
2010 for mixed code and declarations and 2013 for named initialization
of structs.

I wonder what raising the msvc requirement would imply for supporting
older Windows versions.

One relevant tidbit is that afaict 2013 still allows *targeting* older
versions of windows, down to XP and 2003, while requiring a newer
platforms to run. See:
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-compatibility-vs
I don't know if that's hard to do, but I strongly suspect that the
existing installers already do that (otherwise supporting newer versions
would likely require separate builds).

So, does anyone with Windows build experience want to comment on this?

The proposal is to desupport anything older than (probably) MSVC 2013,
or alternatively anything that cannot compile the attached test file.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachments:

test-c99.ctext/plain; charset=UTF-8; name=test-c99.c; x-mac-creator=0; x-mac-type=0Download
#56Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#55)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

So, does anyone with Windows build experience want to comment on this?
The proposal is to desupport anything older than (probably) MSVC 2013,
or alternatively anything that cannot compile the attached test file.

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

regards, tom lane

#57Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#56)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-21 13:29:20 -0400, Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

So, does anyone with Windows build experience want to comment on this?
The proposal is to desupport anything older than (probably) MSVC 2013,
or alternatively anything that cannot compile the attached test file.

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

I think we pretty much know the answer already, anything before 2013
will fail. The question is more whether that's problematic for the
people building on windows. My theory, quoted by Peter upthread, is
that it shouldn't be problematic because 2013 can build binaries that
run on XP etc.

Greetings,

Andres Freund

#58Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#57)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Andres Freund <andres@anarazel.de> writes:

On 2018-08-21 13:29:20 -0400, Tom Lane wrote:

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

I think we pretty much know the answer already, anything before 2013
will fail.

Do we know that for sure? I thought it was theoretical.

regards, tom lane

#59Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#58)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-21 13:46:10 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-21 13:29:20 -0400, Tom Lane wrote:

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

I think we pretty much know the answer already, anything before 2013
will fail.

Do we know that for sure? I thought it was theoretical.

Pretty much. I'm on mobile data so I don't want to search too much, but
I've previously looked it up, and designated initializer support was
introduced in 2013. See e.g. the graph in
https://blogs.msdn.microsoft.com/somasegar/2013/06/28/c-conformance-roadmap/

Greetings,

Andres Freund

#60Chapman Flack
chap@anastigmatix.net
In reply to: Tom Lane (#58)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/21/2018 01:46 PM, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-21 13:29:20 -0400, Tom Lane wrote:

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

I think we pretty much know the answer already, anything before 2013
will fail.

Do we know that for sure? I thought it was theoretical.

I thought I remembered a message where it had been looked up in docs,
but I think the one I was remembering was Peter's "According to my
research (completely untested in practice), you need 2010 for
mixed code and declarations and 2013 for named initialization
of structs." [1]/messages/by-id/ef986aa7-c7ca-ec34-19d9-fef38716b109@2ndquadrant.com which didn't quite actually say it was documented.

-Chap

[1]: /messages/by-id/ef986aa7-c7ca-ec34-19d9-fef38716b109@2ndquadrant.com
/messages/by-id/ef986aa7-c7ca-ec34-19d9-fef38716b109@2ndquadrant.com

#61Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Andres Freund (#57)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/21/2018 01:31 PM, Andres Freund wrote:

Hi,

On 2018-08-21 13:29:20 -0400, Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

So, does anyone with Windows build experience want to comment on this?
The proposal is to desupport anything older than (probably) MSVC 2013,
or alternatively anything that cannot compile the attached test file.

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

I think we pretty much know the answer already, anything before 2013
will fail. The question is more whether that's problematic for the
people building on windows. My theory, quoted by Peter upthread, is
that it shouldn't be problematic because 2013 can build binaries that
run on XP etc.

XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#62Joshua D. Drake
jd@commandprompt.com
In reply to: Andrew Dunstan (#61)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/21/2018 11:06 AM, Andrew Dunstan wrote:

XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.

I wouldn't think XP should even be on our list anymore. Microsoft hasn't
supported it in 4 years.

JD

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
*** A fault and talent of mine is to tell it exactly how it is. ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
***** Unless otherwise stated, opinions are my own. *****

#63Andres Freund
andres@anarazel.de
In reply to: Andrew Dunstan (#61)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 2018-08-21 14:06:18 -0400, Andrew Dunstan wrote:

On 08/21/2018 01:31 PM, Andres Freund wrote:

Hi,

On 2018-08-21 13:29:20 -0400, Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

So, does anyone with Windows build experience want to comment on this?
The proposal is to desupport anything older than (probably) MSVC 2013,
or alternatively anything that cannot compile the attached test file.

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

I think we pretty much know the answer already, anything before 2013
will fail. The question is more whether that's problematic for the
people building on windows. My theory, quoted by Peter upthread, is
that it shouldn't be problematic because 2013 can build binaries that
run on XP etc.

XP at least is essentially a dead platform for us. My animals are not able
to build anything after release 10.

I'm perfectly fine with that, FWIW. It's out of extended support for
several years now. But my point was that you can newer versions of MSVC
to build things that run on XP (and more relevantly 2008, vista, 7 etc).
No idea if we'd need to change anything in our build infra for that.

Greetings,

Andres Freund

#64Andres Freund
andres@anarazel.de
In reply to: Joshua D. Drake (#62)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:

On 08/21/2018 11:06 AM, Andrew Dunstan wrote:

XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.

I wouldn't think XP should even be on our list anymore. Microsoft hasn't
supported it in 4 years.

XP isn't the only thing relevant here, vista and 2008 R1 are in the same
class.

Greetings,

Andres Freund

#65Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Andres Freund (#64)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/21/2018 04:49 PM, Andres Freund wrote:

On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:

On 08/21/2018 11:06 AM, Andrew Dunstan wrote:

XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.

I wouldn't think XP should even be on our list anymore. Microsoft hasn't
supported it in 4 years.

XP isn't the only thing relevant here, vista and 2008 R1 are in the same
class.

I do have a machine in my laptop graveyard with Vista. The only WS2008
instace I have available is R2 and AWS doesn't seem to have any AMIs for R1.

Honestly, I don't think these matter terribly much. Anyone building now
is not likely to be targeting them.

Of the buildfarm animals, dory looks OK, hamerkop, bowerbird and thrips
look not ok, and whelk and woodlouse look borderline.

I'm perfectly prepared to upgrade bowerbird if necessary.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#66Andres Freund
andres@anarazel.de
In reply to: Andrew Dunstan (#65)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote:

On 08/21/2018 04:49 PM, Andres Freund wrote:

On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:

On 08/21/2018 11:06 AM, Andrew Dunstan wrote:

XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.

I wouldn't think XP should even be on our list anymore. Microsoft hasn't
supported it in 4 years.

XP isn't the only thing relevant here, vista and 2008 R1 are in the same
class.

I do have a machine in my laptop graveyard with Vista. The only WS2008
instace I have available is R2 and AWS doesn't seem to have any AMIs for R1.

Honestly, I don't think these matter terribly much. Anyone building now is
not likely to be targeting them.

I agree, I think we should just decree that the minimum is MSVC 2013 and
that people building 12 need to deal with that. I would personally
*additionally* would say that we officially don't support *running* (not
compiling) on XP, 2003, 2008R1 and Vista (all unsupported by MS) - but
that's a somewhat orthogonal decision.

Greetings,

Andres Freund

#67Amit Kapila
amit.kapila16@gmail.com
In reply to: Tom Lane (#58)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On Tue, Aug 21, 2018 at 11:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-21 13:29:20 -0400, Tom Lane wrote:

We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.

I think we pretty much know the answer already, anything before 2013
will fail.

Do we know that for sure? I thought it was theoretical.

I have MSVC 2010 on my Windows 7 VM where I have tried the C99
constructs provided by Peter E. and below are my findings:

Tried compiling below function in one of the .c files in the src/backend
-----------------------------------------------------------------------------------------------
int
bar()
{
int x;
x = 1;
int y;
y = 2;

for (int i = 0; i < 5; i++)
;

return 0;
}

error C2143: syntax error : missing ';' before 'type'
error C2065: 'y' : undeclared identifier
error C2143: syntax error : missing ';' before 'type'
error C2143: syntax error : missing ';' before 'type'
error C2143: syntax error : missing ')' before 'type'
error C2143: syntax error : missing ';' before 'type'
error C2065: 'i' : undeclared identifier
warning C4552: '<' : operator has no effect; expected operator with side-effect
error C2065: 'i' : undeclared identifier
error C2059: syntax error : ')'

Tried compiling below struct in one of the .c files in the src/backend
-----------------------------------------------------------------------------------------------
struct foo
{
int a;
int b;
};

struct foo f = {
.a = 1,
.b = 2
};

error C2059: syntax error : '.'

I have also tried compiling above in standalone console application
project in MSVC 2010 and able to compile the function successfully,
but struct is giving the same error as above. So, it seems to me that
it won't work on <= MSVC 2010. I am personally okay with upgrading my
Windows VM.

I have found a couple of links which suggest that MSVC 2015 has a good
amount of conformance with C99 [1]https://social.msdn.microsoft.com/Forums/en-US/fa17bcdd-7165-4645-a676-ef3797b95918/details-on-c99-support-in-msvc?forum=vcgeneral. It seems MSVC 2013 also has
decent support for C99 [2]https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/, but I am not able to verify if the
constructs shared by Peter E can be compiled on it.

[1]: https://social.msdn.microsoft.com/Forums/en-US/fa17bcdd-7165-4645-a676-ef3797b95918/details-on-c99-support-in-msvc?forum=vcgeneral
[2]: https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

#68Sandeep Thakkar
sandeep.thakkar@enterprisedb.com
In reply to: Andres Freund (#38)
Re: C99 compliance for src/port/snprintf.c

Hi

On Thu, Aug 16, 2018 at 6:30 PM, Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2018-08-16 14:28:25 +0200, Peter Eisentraut wrote:

On 16/08/2018 01:06, Andres Freund wrote:

So it looks like msvc 2013 might be the relevant requirement.

According to my research (completely untested in practice), you need
2010 for mixed code and declarations and 2013 for named initialization
of structs.

I wonder what raising the msvc requirement would imply for supporting
older Windows versions.

One relevant tidbit is that afaict 2013 still allows *targeting* older
versions of windows, down to XP and 2003, while requiring a newer
platforms to run. See:
https://docs.microsoft.com/en-us/visualstudio/productinfo/
vs2013-compatibility-vs
I don't know if that's hard to do, but I strongly suspect that the
existing installers already do that (otherwise supporting newer versions
would likely require separate builds).

2013 still runs on Windows 7, should you want that:
https://docs.microsoft.com/en-us/visualstudio/productinfo/
vs2013-sysrequirements-vs

According to https://www.postgresql.org/download/windows/
the available binaries already effectively restrict windows support:

EDB installers, for 10, restrict to:
64 Bit Windows: 2016, 2012 R2 & R1, 2008 R2, 7, 8, 10
32 Bit Windows: 2008 R1, 7, 8, 10

BIGSQL to: Windows 10 and Windows Server 2012.

Of those 2013 only doesn't run on 2008 R1 anymore. Which still can be
targeted from the newer windows versions.

It'd be good to get confirmation that the windows binaries / installers
are indeed built on newer platforms than the oldest supported version.

We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2.

For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
2013. For v11, we use 2017.

Random observation: http://www.openscg.com/bigsql/postgresql/installers/
seems to indicate that packages aren't updated anymore. While it says
"(09-Aug-18)" besides the major versions, it does not actually in fact
have the last set of minor releases. I suspect that's related to
openscg's acquisition by amazon? Either they need to catch up, or we
need to take down the page and probably alert people about that fact.

Greetings,

Andres Freund

--
Sandeep Thakkar

#69Sandeep Thakkar
sandeep.thakkar@enterprisedb.com
In reply to: Andres Freund (#66)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On Wed, Aug 22, 2018 at 4:59 AM, Andres Freund <andres@anarazel.de> wrote:

On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote:

On 08/21/2018 04:49 PM, Andres Freund wrote:

On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:

On 08/21/2018 11:06 AM, Andrew Dunstan wrote:

XP at least is essentially a dead platform for us. My animals are

not

able to build anything after release 10.

I wouldn't think XP should even be on our list anymore. Microsoft

hasn't

supported it in 4 years.

XP isn't the only thing relevant here, vista and 2008 R1 are in the

same

class.

I do have a machine in my laptop graveyard with Vista. The only WS2008
instace I have available is R2 and AWS doesn't seem to have any AMIs for

R1.

Honestly, I don't think these matter terribly much. Anyone building now

is

not likely to be targeting them.

I agree, I think we should just decree that the minimum is MSVC 2013 and
that people building 12 need to deal with that. I would personally
*additionally* would say that we officially don't support *running* (not
compiling) on XP, 2003, 2008R1 and Vista (all unsupported by MS) - but
that's a somewhat orthogonal decision.

We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2.

For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
2013. For v11, we use 2017.

Greetings,

Andres Freund

--
Sandeep Thakkar

#70Andres Freund
andres@anarazel.de
In reply to: Sandeep Thakkar (#69)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote:

We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2.

For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
2013. For v11, we use 2017.

Sndeep: Thanks for the information. Did you ever encounter problems (at
build or during runtime) with using those binaries on older platforms?

Everyone: Given the fact that all the people building windows packages
currently use a new enough stack by a fair margin, I think we should
conclude that there's no obstacle on the windows side of things.

If we agree on that, I'm going to propose a patch that includes:
- relevant cleanups to configure
- adapts sources.sgml to refer to C99 instead of C89
- add some trivial conversions to for(int i;;) and struct initializers,
so the relevant old animals fail
- adds a configure check to enable errors with vla usage (-Werror=vla)

Questions:

- do we want to make declarations at arbitrary points errors? It's
already a warning currently.
- other new restrictions that we want to introduce at the same time?

Greetings,

Andres Freund

#71Sandeep Thakkar
sandeep.thakkar@enterprisedb.com
In reply to: Andres Freund (#70)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On Wed, Aug 22, 2018 at 5:32 PM, Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote:

We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012

R2.

For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
2013. For v11, we use 2017.

Sndeep: Thanks for the information. Did you ever encounter problems (at
build or during runtime) with using those binaries on older platforms?

IIRC when the binaries were built with VC++ 2013 on 9.4, we had problems

running them on XP and hence we had used "/p:PlatformToolset=v120_xp"
option to msbuild during build time. From v10, we stopped using that
toolset and instead used the default one i.e v120

Everyone: Given the fact that all the people building windows packages
currently use a new enough stack by a fair margin, I think we should
conclude that there's no obstacle on the windows side of things.

If we agree on that, I'm going to propose a patch that includes:
- relevant cleanups to configure
- adapts sources.sgml to refer to C99 instead of C89
- add some trivial conversions to for(int i;;) and struct initializers,
so the relevant old animals fail
- adds a configure check to enable errors with vla usage (-Werror=vla)

Questions:

- do we want to make declarations at arbitrary points errors? It's
already a warning currently.
- other new restrictions that we want to introduce at the same time?

Greetings,

Andres Freund

--
Sandeep Thakkar

#72Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Andres Freund (#70)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 22/08/2018 14:02, Andres Freund wrote:

If we agree on that, I'm going to propose a patch that includes:
- relevant cleanups to configure
- adapts sources.sgml to refer to C99 instead of C89
- add some trivial conversions to for(int i;;) and struct initializers,
so the relevant old animals fail
- adds a configure check to enable errors with vla usage (-Werror=vla)

sounds good

- do we want to make declarations at arbitrary points errors? It's
already a warning currently.

While there are legitimate criticisms, it's a standard feature in C,
C++, and many other languages, so I don't see what we'd gain by fighting it.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#73Andres Freund
andres@anarazel.de
In reply to: Peter Eisentraut (#72)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-22 16:56:15 +0200, Peter Eisentraut wrote:

On 22/08/2018 14:02, Andres Freund wrote:

- do we want to make declarations at arbitrary points errors? It's
already a warning currently.

While there are legitimate criticisms, it's a standard feature in C,
C++, and many other languages, so I don't see what we'd gain by fighting it.

I personally don't really care - for C there's really not much of a
difference (contrast to C++ with RAII). But Robert and Tom both said
this would be an issue with moving to C99 for them. I don't want to hold
up making progress here by fighting over this issue.

Greetings,

Andres Freund

#74David Steele
david@pgmasters.net
In reply to: Peter Eisentraut (#72)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 8/22/18 10:56 AM, Peter Eisentraut wrote:

On 22/08/2018 14:02, Andres Freund wrote:

If we agree on that, I'm going to propose a patch that includes:
- relevant cleanups to configure
- adapts sources.sgml to refer to C99 instead of C89
- add some trivial conversions to for(int i;;) and struct initializers,
so the relevant old animals fail
- adds a configure check to enable errors with vla usage (-Werror=vla)

sounds good

Sounds good to me.

- do we want to make declarations at arbitrary points errors? It's
already a warning currently.

While there are legitimate criticisms, it's a standard feature in C,
C++, and many other languages, so I don't see what we'd gain by fighting it.

+1.=

--
-David
david@pgmasters.net

#75Andres Freund
andres@anarazel.de
In reply to: Andres Freund (#70)
4 attachment(s)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-22 05:02:11 -0700, Andres Freund wrote:

If we agree on that, I'm going to propose a patch that includes:
- relevant cleanups to configure
- adapts sources.sgml to refer to C99 instead of C89
- add some trivial conversions to for(int i;;) and struct initializers,
so the relevant old animals fail
- adds a configure check to enable errors with vla usage (-Werror=vla)

Questions:

- do we want to make declarations at arbitrary points errors? It's
already a warning currently.
- other new restrictions that we want to introduce at the same time?

Attached is a version doing so. Turns out ripping < msvc 2010 support
allows us to get rid of a fair bit of code. Using appveyor I tested
that I didn't bungle things too badly. But I don't really know what I'm
doing in that area, Andrew or Craig, your input would be appreciated.

I tried to update sources.sgml to reflect my understanding of the subset
of C99 we're going to use. I'd rather start more restrictive and then
argue about relaxing things separately.

There's a few further potential cleanups due to relying on c99:
- Use __func__ unconditionally, rather than having configure test for it
- Use inline unconditionally, rather than having configure test for it
- Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
AC_TYPE_LONG_LONG_INT, we can rely on them being present.
- probably more in that vein

I'd rather do these separately lateron, in case one of them causes
trouble on some animals.

There's some potential ones I think we should *not* do:
- remove AC_C_FLEXIBLE_ARRAY_MEMBER, and rely on it unconditionally.
I'm disinclined to do this, because C++ IIRC doesn't support it in any
version, and I don't want to make Peter's life unnecessarily hard.
- remove AC_C_RESTRICT check, rely on it unconditionally: MSVC still
spells this differently.

Greetings,

Andres Freund

Attachments:

v1-0001-Require-C99-and-thus-MSCV-2013-upwards.patchtext/x-diff; charset=us-asciiDownload
From c579be2ae7a020d6005d84a5b6f24872ba8b1b05 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 15:10:23 -0700
Subject: [PATCH v1 1/4] Require C99 (and thus MSCV 2013 upwards).

Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
 configure                        | 49 ++++++++++++++++++++++++++++++++
 configure.in                     | 10 +++++++
 doc/src/sgml/sources.sgml        | 33 ++++++++++++++-------
 src/tools/msvc/MSBuildProject.pm |  2 +-
 src/tools/msvc/README            |  6 ++--
 src/tools/msvc/build.pl          |  6 +---
 6 files changed, 86 insertions(+), 20 deletions(-)

diff --git a/configure b/configure
index 836d68dad37..dd439ddd2f6 100755
--- a/configure
+++ b/configure
@@ -4602,6 +4602,13 @@ if test "x$ac_cv_prog_cc_c99" != xno; then :
 fi
 
 
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+    as_fn_error $? "C compiler \"$CC\" does not support C99" "$LINENO" 5
+fi
+
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
 ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
@@ -5361,6 +5368,48 @@ fi
 
 
   # -Wdeclaration-after-statement isn't applicable for C++
+  # Really don't want VLAs to be used in our dialect of C
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Werror=vla, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -Werror=vla, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__Werror_vla+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -Werror=vla"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  pgac_cv_prog_CC_cflags__Werror_vla=yes
+else
+  pgac_cv_prog_CC_cflags__Werror_vla=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__Werror_vla" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__Werror_vla" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__Werror_vla" = x"yes"; then
+  CFLAGS="${CFLAGS} -Werror=vla"
+fi
+
+
+  # -Wvla is not applicable for C++
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Wendif-labels, for CFLAGS" >&5
 $as_echo_n "checking whether ${CC} supports -Wendif-labels, for CFLAGS... " >&6; }
diff --git a/configure.in b/configure.in
index 6e141064e5c..5869ab7c5bc 100644
--- a/configure.in
+++ b/configure.in
@@ -359,6 +359,13 @@ esac
 
 AC_PROG_CC([$pgac_cc_list])
 AC_PROG_CC_C99()
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+    AC_MSG_ERROR([C compiler "$CC" does not support C99])
+fi
+
 AC_PROG_CXX([$pgac_cxx_list])
 
 # Check if it's Intel's compiler, which (usually) pretends to be gcc,
@@ -477,6 +484,9 @@ if test "$GCC" = yes -a "$ICC" = no; then
   # These work in some but not all gcc versions
   PGAC_PROG_CC_CFLAGS_OPT([-Wdeclaration-after-statement])
   # -Wdeclaration-after-statement isn't applicable for C++
+  # Really don't want VLAs to be used in our dialect of C
+  PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])
+  # -Wvla is not applicable for C++
   PGAC_PROG_CC_CFLAGS_OPT([-Wendif-labels])
   PGAC_PROG_CXX_CFLAGS_OPT([-Wendif-labels])
   PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
index e53ee1dc6ad..419f753c7bc 100644
--- a/doc/src/sgml/sources.sgml
+++ b/doc/src/sgml/sources.sgml
@@ -867,19 +867,30 @@ BETTER: unrecognized node type: 42
     <title>C Standard</title>
     <para>
      Code in <productname>PostgreSQL</productname> should only rely on language
-     features available in the C89 standard. That means a conforming
-     C89 compiler has to be able to compile postgres, at least aside
-     from a few platform dependent pieces. Features from later
-     revision of the C standard or compiler specific features can be
-     used, if a fallback is provided.
+     features available in the C99 standard. That means a conforming
+     C99 compiler has to be able to compile postgres, at least aside
+     from a few platform dependent pieces.
     </para>
     <para>
-     For example <literal>static inline</literal> and
-     <literal>_StaticAssert()</literal> are currently used, even
-     though they are from newer revisions of the C standard. If not
-     available we respectively fall back to defining the functions
-     without inline, and to using a C89 compatible replacement that
-     performs the same checks, but emits rather cryptic messages.
+     A few features included in the C99 standard are, at this time, not be
+     permitted to be used in core <productname>PostgreSQL</productname>
+     code. This currently includes variable length arrays, intermingled
+     declarations and code, <literal>//</literal> comments, universal
+     character names. Reasons for that include portability and historical
+     practices.
+    </para>
+    <para>
+     Features from later revision of the C standard or compiler specific
+     features can be used, if a fallback is provided.
+    </para>
+    <para>
+     For example <literal>_StaticAssert()</literal> and
+     <literal>__builtin_constant_p</literal> are currently used, even though
+     they are from newer revisions of the C standard and a
+     <productname>GCC</productname> extension respectively. If not available
+     we respectively fall back to using a C99 compatible replacement that
+     performs the same checks, but emits rather cryptic messages and do not
+     use <literal>__builtin_constant_p</literal>.
     </para>
    </simplesect>
 
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index 47252533a1b..dd6a610e5b2 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -1,7 +1,7 @@
 package MSBuildProject;
 
 #
-# Package that encapsulates a MSBuild project file (Visual C++ 2010 or greater)
+# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
 #
 # src/tools/msvc/MSBuildProject.pm
 #
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index bfa98045f22..2827d76b2d1 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -67,7 +67,7 @@ Install.pm             module containing the install logic
 Mkvcbuild.pm           module containing the code to generate the Visual
                        Studio build (project/solution) files
 MSBuildProject.pm      module containing the code to generate MSBuild based
-                       project files (Visual Studio 2010 or greater)
+                       project files (Visual Studio 2013 or greater)
 Project.pm             module containing the common code to generate the
                        Visual Studio project files. Also provides the
                        common interface of all project file generators
@@ -99,5 +99,5 @@ VC2010Project or VC2012Project or VC2013Project or VC2015Project or VC2017Projec
 from MSBuildProject.pm) to it.
 When Solution::Save is called, the implementations of Solution and Project
 save their content in the appropriate format.
-The final step of starting the appropriate build program (msbuild or vcbuild)
-is performed in build.pl again.
+The final step of starting the appropriate build program (msbuild) is
+performed in build.pl again.
diff --git a/src/tools/msvc/build.pl b/src/tools/msvc/build.pl
index 9a234d1cc25..35649fe5a24 100644
--- a/src/tools/msvc/build.pl
+++ b/src/tools/msvc/build.pl
@@ -53,16 +53,12 @@ elsif (uc($ARGV[0]) ne "RELEASE")
 
 # ... and do it
 
-if ($buildwhat and $vcver >= 10.00)
+if ($buildwhat)
 {
 	system(
 		"msbuild $buildwhat.vcxproj /verbosity:normal $msbflags /p:Configuration=$bconf"
 	);
 }
-elsif ($buildwhat)
-{
-	system("vcbuild $msbflags $buildwhat.vcproj $bconf");
-}
 else
 {
 	system(
-- 
2.18.0.rc2.dirty

v1-0002-Remove-test-for-VA_ARGS-implied-by-C99.patchtext/x-diff; charset=us-asciiDownload
From 5f6bedf514c9fa30ce5f3f3e88e95f77a2bde91c Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:04:47 -0700
Subject: [PATCH v1 2/4] Remove test for VA_ARGS, implied by C99.

Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
 config/c-compiler.m4              |  19 --
 configure                         |  34 +---
 configure.in                      |   1 -
 doc/src/sgml/install-windows.sgml |  26 +--
 src/include/pg_config.h.in        |   3 -
 src/include/pg_config.h.win32     |   3 -
 src/include/utils/elog.h          |   8 +-
 src/pl/plpython/plpy_elog.h       |   4 -
 src/tools/msvc/MSBuildProject.pm  |  76 +-------
 src/tools/msvc/README             |  12 +-
 src/tools/msvc/Solution.pm        | 102 ----------
 src/tools/msvc/VCBuildProject.pm  | 309 ------------------------------
 src/tools/msvc/VSObjectFactory.pm |  37 +---
 13 files changed, 27 insertions(+), 607 deletions(-)
 delete mode 100644 src/tools/msvc/VCBuildProject.pm

diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 67675a31bb6..eedaf12d69c 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -415,25 +415,6 @@ fi])# PGAC_C_COMPUTED_GOTO
 
 
 
-# PGAC_C_VA_ARGS
-# --------------
-# Check if the C compiler understands C99-style variadic macros,
-# and define HAVE__VA_ARGS if so.
-AC_DEFUN([PGAC_C_VA_ARGS],
-[AC_CACHE_CHECK(for __VA_ARGS__, pgac_cv__va_args,
-[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <stdio.h>],
-[#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-])],
-[pgac_cv__va_args=yes],
-[pgac_cv__va_args=no])])
-if test x"$pgac_cv__va_args" = xyes ; then
-AC_DEFINE(HAVE__VA_ARGS, 1,
-          [Define to 1 if your compiler understands __VA_ARGS__ in macros.])
-fi])# PGAC_C_VA_ARGS
-
-
-
 # PGAC_PROG_VARCC_VARFLAGS_OPT
 # -----------------------
 # Given a compiler, variable name and a string, check if the compiler
diff --git a/configure b/configure
index dd439ddd2f6..af090ffb08f 100755
--- a/configure
+++ b/configure
@@ -13962,38 +13962,6 @@ if test x"$pgac_cv_computed_goto" = xyes ; then
 
 $as_echo "#define HAVE_COMPUTED_GOTO 1" >>confdefs.h
 
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __VA_ARGS__" >&5
-$as_echo_n "checking for __VA_ARGS__... " >&6; }
-if ${pgac_cv__va_args+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-#include <stdio.h>
-int
-main ()
-{
-#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  pgac_cv__va_args=yes
-else
-  pgac_cv__va_args=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__va_args" >&5
-$as_echo "$pgac_cv__va_args" >&6; }
-if test x"$pgac_cv__va_args" = xyes ; then
-
-$as_echo "#define HAVE__VA_ARGS 1" >>confdefs.h
-
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether struct tm is in sys/time.h or time.h" >&5
 $as_echo_n "checking whether struct tm is in sys/time.h or time.h... " >&6; }
@@ -19635,7 +19603,7 @@ PostgreSQL config.status 12devel
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
-Copyright (C) 2012 Free Software Foundation, Inc.
+Copyright (C)  Free Software Foundation, Inc.
 This config.status script is free software; the Free Software Foundation
 gives unlimited permission to copy, distribute and modify it."
 
diff --git a/configure.in b/configure.in
index 5869ab7c5bc..3280afa0dab 100644
--- a/configure.in
+++ b/configure.in
@@ -1434,7 +1434,6 @@ PGAC_C_BUILTIN_BSWAP64
 PGAC_C_BUILTIN_CONSTANT_P
 PGAC_C_BUILTIN_UNREACHABLE
 PGAC_C_COMPUTED_GOTO
-PGAC_C_VA_ARGS
 PGAC_STRUCT_TIMEZONE
 PGAC_UNION_SEMUN
 PGAC_STRUCT_SOCKADDR_UN
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 9597bc35a14..22a2ffd55ee 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -22,7 +22,7 @@
   Microsoft tools is to install <productname>Visual Studio Express 2017
   for Windows Desktop</productname> and use the included
   compiler. It is also possible to build with the full
-  <productname>Microsoft Visual C++ 2005 to 2017</productname>.
+  <productname>Microsoft Visual C++ 2013 to 2017</productname>.
   In some cases that requires the installation of the
   <productname>Windows SDK</productname> in addition to the compiler.
  </para>
@@ -77,20 +77,24 @@
  <para>
   Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
   32-bit PostgreSQL builds are possible with
-  <productname>Visual Studio 2005</productname> to
+  <productname>Visual Studio 2013</productname> to
   <productname>Visual Studio 2017</productname> (including Express editions),
   as well as standalone Windows SDK releases 6.0 to 8.1.
   64-bit PostgreSQL builds are supported with
   <productname>Microsoft Windows SDK</productname> version 6.0a to 8.1 or
-  <productname>Visual Studio 2008</productname> and above. Compilation
-  is supported down to <productname>Windows XP</productname> and
-  <productname>Windows Server 2003</productname> when building with
-  <productname>Visual Studio 2005</productname> to
-  <productname>Visual Studio 2013</productname>. Building with
-  <productname>Visual Studio 2015</productname> is supported down to
-  <productname>Windows Vista</productname> and <productname>Windows Server 2008</productname>.
-   Building with <productname>Visual Studio 2017</productname> is supported
-   down to <productname>Windows 7 SP1</productname> and <productname>Windows Server 2008 R2 SP1</productname>.
+  <productname>Visual Studio 2013</productname> and above. Compilation
+  is supported down to <productname>Windows 7</productname> and
+  <productname>Windows Server 2008 R2 SP1</productname> when building with
+  <productname>Visual Studio 2013</productname> to
+  <productname>Visual Studio 2017</productname>.
+   <!--
+       For 2013 requirements:
+       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
+       For 2015 requirements:
+       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
+       For 2017 requirements:
+       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
+   -->
  </para>
 
  <para>
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index 827574ee40d..37649d77d67 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -754,9 +754,6 @@
 /* Define to 1 if your compiler understands _Static_assert. */
 #undef HAVE__STATIC_ASSERT
 
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#undef HAVE__VA_ARGS
-
 /* Define to 1 if you have the `__strtoll' function. */
 #undef HAVE___STRTOLL
 
diff --git a/src/include/pg_config.h.win32 b/src/include/pg_config.h.win32
index 46ce49def2f..4e2bd3c1352 100644
--- a/src/include/pg_config.h.win32
+++ b/src/include/pg_config.h.win32
@@ -597,9 +597,6 @@
 /* Define to 1 if your compiler understands _Static_assert. */
 /* #undef HAVE__STATIC_ASSERT */
 
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#define HAVE__VA_ARGS 1
-
 /* Define to the appropriate printf length modifier for 64-bit ints. */
 #define INT64_MODIFIER "ll"
 
diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h
index 4350b120aab..33c6b53e278 100644
--- a/src/include/utils/elog.h
+++ b/src/include/utils/elog.h
@@ -207,9 +207,8 @@ extern int	getinternalerrposition(void);
  *		elog(ERROR, "portal \"%s\" not found", stmt->portalname);
  *----------
  */
-#ifdef HAVE__VA_ARGS
 /*
- * If we have variadic macros, we can give the compiler a hint about the
+ * Using variadic macros, we can give the compiler a hint about the
  * call not returning when elevel >= ERROR.  See comments for ereport().
  * Note that historically elog() has called elog_start (which saves errno)
  * before evaluating "elevel", so we preserve that behavior here.
@@ -236,11 +235,6 @@ extern int	getinternalerrposition(void);
 		} \
 	} while(0)
 #endif							/* HAVE__BUILTIN_CONSTANT_P */
-#else							/* !HAVE__VA_ARGS */
-#define elog  \
-	elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), \
-	elog_finish
-#endif							/* HAVE__VA_ARGS */
 
 extern void elog_start(const char *filename, int lineno, const char *funcname);
 extern void elog_finish(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
diff --git a/src/pl/plpython/plpy_elog.h b/src/pl/plpython/plpy_elog.h
index e4b30c3cca1..b56ac412476 100644
--- a/src/pl/plpython/plpy_elog.h
+++ b/src/pl/plpython/plpy_elog.h
@@ -15,7 +15,6 @@ extern PyObject *PLy_exc_spi_error;
  *
  * See comments at elog() about the compiler hinting.
  */
-#ifdef HAVE__VA_ARGS
 #ifdef HAVE__BUILTIN_CONSTANT_P
 #define PLy_elog(elevel, ...) \
 	do { \
@@ -32,9 +31,6 @@ extern PyObject *PLy_exc_spi_error;
 			pg_unreachable(); \
 	} while(0)
 #endif							/* HAVE__BUILTIN_CONSTANT_P */
-#else							/* !HAVE__VA_ARGS */
-#define PLy_elog PLy_elog_impl
-#endif							/* HAVE__VA_ARGS */
 
 extern void PLy_elog_impl(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
 
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index dd6a610e5b2..149213378cf 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -257,6 +257,7 @@ sub WriteConfigurationPropertyGroup
     <UseOfMfc>false</UseOfMfc>
     <CharacterSet>MultiByte</CharacterSet>
     <WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
+    <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
   </PropertyGroup>
 EOF
 	return;
@@ -391,75 +392,6 @@ EOF
 	return;
 }
 
-package VC2010Project;
-
-#
-# Package that encapsulates a Visual C++ 2010 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver} = '10.00';
-
-	return $self;
-}
-
-package VC2012Project;
-
-#
-# Package that encapsulates a Visual C++ 2012 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver}           = '11.00';
-	$self->{PlatformToolset} = 'v110';
-
-	return $self;
-}
-
-# This override adds the <PlatformToolset> element
-# to the PropertyGroup labeled "Configuration"
-sub WriteConfigurationPropertyGroup
-{
-	my ($self, $f, $cfgname, $p) = @_;
-	my $cfgtype =
-	  ($self->{type} eq "exe")
-	  ? 'Application'
-	  : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary');
-
-	print $f <<EOF;
-  <PropertyGroup Condition="'\$(Configuration)|\$(Platform)'=='$cfgname|$self->{platform}'" Label="Configuration">
-    <ConfigurationType>$cfgtype</ConfigurationType>
-    <UseOfMfc>false</UseOfMfc>
-    <CharacterSet>MultiByte</CharacterSet>
-    <WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
-    <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
-  </PropertyGroup>
-EOF
-	return;
-}
-
 package VC2013Project;
 
 #
@@ -468,7 +400,7 @@ package VC2013Project;
 
 use strict;
 use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
 
 no warnings qw(redefine);    ## no critic
 
@@ -493,7 +425,7 @@ package VC2015Project;
 
 use strict;
 use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
 
 no warnings qw(redefine);    ## no critic
 
@@ -518,7 +450,7 @@ package VC2017Project;
 
 use strict;
 use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
 
 no warnings qw(redefine);    ## no critic
 
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index 2827d76b2d1..4ab81d3402f 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
 ==========
 
 This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2005 - 2017. This builds the whole backend, not just
+Microsoft Visual Studio 2013 - 2017. This builds the whole backend, not just
 the libpq frontend library. For more information, see the documentation
 chapter "Installation on Windows" and the description below.
 
@@ -73,8 +73,6 @@ Project.pm             module containing the common code to generate the
                        common interface of all project file generators
 Solution.pm            module containing the code to generate the Visual
                        Studio solution files.
-VCBuildProject.pm      module containing the code to generate VCBuild based
-                       project files (Visual Studio 2005/2008)
 VSObjectFactory.pm     factory module providing the code to create the
                        appropriate project/solution files for the current
                        environment
@@ -90,13 +88,11 @@ config_default.pl to create the configuration arguments.
 These configuration arguments are passed over to Mkvcbuild::mkvcbuild
 (Mkvcbuild.pm) which creates the Visual Studio project and solution files.
 It does this by using VSObjectFactory::CreateSolution to create an object
-implementing the Solution interface (this could be either a VS2005Solution,
-a VS2008Solution, a VS2010Solution or a VS2012Solution or a VS2013Solution,
+implementing the Solution interface (this could be either a VS2013Solution,
 or a VS2015Solution or a VS2017Solution, all in Solution.pm, depending on
 the user's build environment) and adding objects implementing the corresponding
-Project interface (VC2005Project or VC2008Project from VCBuildProject.pm or
-VC2010Project or VC2012Project or VC2013Project or VC2015Project or VC2017Project
-from MSBuildProject.pm) to it.
+Project interface (VC2013Project or VC2015Project or VC2017Project from
+MSBuildProject.pm) to it.
 When Solution::Save is called, the implementations of Solution and Project
 save their content in the appropriate format.
 The final step of starting the appropriate build program (msbuild) is
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 78db247b291..7d7ce8b0312 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -760,108 +760,6 @@ sub GetFakeConfigure
 	return $cfg;
 }
 
-package VS2005Solution;
-
-#
-# Package that encapsulates a Visual Studio 2005 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '9.00';
-	$self->{vcver}               = '8.00';
-	$self->{visualStudioName}    = 'Visual Studio 2005';
-
-	return $self;
-}
-
-package VS2008Solution;
-
-#
-# Package that encapsulates a Visual Studio 2008 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '10.00';
-	$self->{vcver}               = '9.00';
-	$self->{visualStudioName}    = 'Visual Studio 2008';
-
-	return $self;
-}
-
-package VS2010Solution;
-
-#
-# Package that encapsulates a Visual Studio 2010 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '11.00';
-	$self->{vcver}               = '10.00';
-	$self->{visualStudioName}    = 'Visual Studio 2010';
-
-	return $self;
-}
-
-package VS2012Solution;
-
-#
-# Package that encapsulates a Visual Studio 2012 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '12.00';
-	$self->{vcver}               = '11.00';
-	$self->{visualStudioName}    = 'Visual Studio 2012';
-
-	return $self;
-}
-
 package VS2013Solution;
 
 #
diff --git a/src/tools/msvc/VCBuildProject.pm b/src/tools/msvc/VCBuildProject.pm
deleted file mode 100644
index 6cdf822a637..00000000000
--- a/src/tools/msvc/VCBuildProject.pm
+++ /dev/null
@@ -1,309 +0,0 @@
-package VCBuildProject;
-
-#
-# Package that encapsulates a VCBuild (Visual C++ 2005/2008) project file
-#
-# src/tools/msvc/VCBuildProject.pm
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Project);
-
-no warnings qw(redefine);    ## no critic
-
-sub _new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{filenameExtension} = '.vcproj';
-
-	return $self;
-}
-
-sub WriteHeader
-{
-	my ($self, $f) = @_;
-
-	print $f <<EOF;
-<?xml version="1.0" encoding="Windows-1252"?>
-<VisualStudioProject ProjectType="Visual C++" Version="$self->{vcver}" Name="$self->{name}" ProjectGUID="$self->{guid}">
- <Platforms><Platform Name="$self->{platform}"/></Platforms>
- <Configurations>
-EOF
-
-	$self->WriteConfiguration(
-		$f, 'Debug',
-		{
-			defs     => "_DEBUG;DEBUG=1",
-			wholeopt => 0,
-			opt      => 0,
-			strpool  => 'false',
-			runtime  => 3
-		});
-	$self->WriteConfiguration(
-		$f,
-		'Release',
-		{
-			defs     => "",
-			wholeopt => 0,
-			opt      => 3,
-			strpool  => 'true',
-			runtime  => 2
-		});
-	print $f <<EOF;
- </Configurations>
-EOF
-	$self->WriteReferences($f);
-	return;
-}
-
-sub WriteFiles
-{
-	my ($self, $f) = @_;
-	print $f <<EOF;
- <Files>
-EOF
-	my @dirstack = ();
-	my %uniquefiles;
-	foreach my $fileNameWithPath (sort keys %{ $self->{files} })
-	{
-		confess "Bad format filename '$fileNameWithPath'\n"
-		  unless ($fileNameWithPath =~ m!^(.*)/([^/]+)\.(c|cpp|y|l|rc)$!);
-		my $dir  = $1;
-		my $file = $2;
-
-		# Walk backwards down the directory stack and close any dirs
-		# we're done with.
-		while ($#dirstack >= 0)
-		{
-			if (join('/', @dirstack) eq
-				substr($dir, 0, length(join('/', @dirstack))))
-			{
-				last if (length($dir) == length(join('/', @dirstack)));
-				last
-				  if (substr($dir, length(join('/', @dirstack)), 1) eq '/');
-			}
-			print $f ' ' x $#dirstack . "  </Filter>\n";
-			pop @dirstack;
-		}
-
-		# Now walk forwards and create whatever directories are needed
-		while (join('/', @dirstack) ne $dir)
-		{
-			my $left = substr($dir, length(join('/', @dirstack)));
-			$left =~ s/^\///;
-			my @pieces = split /\//, $left;
-			push @dirstack, $pieces[0];
-			print $f ' ' x $#dirstack
-			  . "  <Filter Name=\"$pieces[0]\" Filter=\"\">\n";
-		}
-
-		# VC builds do not like file paths with forward slashes.
-		my $fileNameWithPathFormatted = $fileNameWithPath;
-		$fileNameWithPathFormatted =~ s/\//\\/g;
-
-		print $f ' ' x $#dirstack
-		  . "   <File RelativePath=\"$fileNameWithPathFormatted\"";
-		if ($fileNameWithPath =~ /\.y$/)
-		{
-			my $of = $fileNameWithPath;
-			$of =~ s/\.y$/.c/;
-			$of =~
-			  s{^src/pl/plpgsql/src/gram.c$}{src/pl/plpgsql/src/pl_gram.c};
-			print $f '>'
-			  . $self->GenerateCustomTool(
-				'Running bison on ' . $fileNameWithPath,
-				"perl src/tools/msvc/pgbison.pl $fileNameWithPath", $of)
-			  . '</File>' . "\n";
-		}
-		elsif ($fileNameWithPath =~ /\.l$/)
-		{
-			my $of = $fileNameWithPath;
-			$of =~ s/\.l$/.c/;
-			print $f '>'
-			  . $self->GenerateCustomTool(
-				'Running flex on ' . $fileNameWithPath,
-				"perl src/tools/msvc/pgflex.pl $fileNameWithPath", $of)
-			  . '</File>' . "\n";
-		}
-		elsif (defined($uniquefiles{$file}))
-		{
-
-			# File already exists, so fake a new name
-			my $obj = $dir;
-			$obj =~ s!/!_!g;
-			print $f
-			  "><FileConfiguration Name=\"Debug|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\debug\\$self->{name}\\$obj"
-			  . "_$file.obj\" /></FileConfiguration><FileConfiguration Name=\"Release|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\release\\$self->{name}\\$obj"
-			  . "_$file.obj\" /></FileConfiguration></File>\n";
-		}
-		else
-		{
-			$uniquefiles{$file} = 1;
-			print $f " />\n";
-		}
-	}
-	while ($#dirstack >= 0)
-	{
-		print $f ' ' x $#dirstack . "  </Filter>\n";
-		pop @dirstack;
-	}
-	print $f <<EOF;
- </Files>
-EOF
-	return;
-}
-
-sub Footer
-{
-	my ($self, $f) = @_;
-
-	print $f <<EOF;
- <Globals/>
-</VisualStudioProject>
-EOF
-	return;
-}
-
-sub WriteConfiguration
-{
-	my ($self, $f, $cfgname, $p) = @_;
-	my $cfgtype =
-	  ($self->{type} eq "exe") ? 1 : ($self->{type} eq "dll" ? 2 : 4);
-	my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ' ');
-
-	my $targetmachine = $self->{platform} eq 'Win32' ? 1 : 17;
-
-	print $f <<EOF;
-  <Configuration Name="$cfgname|$self->{platform}" OutputDirectory=".\\$cfgname\\$self->{name}" IntermediateDirectory=".\\$cfgname\\$self->{name}"
-	ConfigurationType="$cfgtype" UseOfMFC="0" ATLMinimizesCRunTimeLibraryUsage="FALSE" CharacterSet="2" WholeProgramOptimization="$p->{wholeopt}">
-	<Tool Name="VCCLCompilerTool" Optimization="$p->{opt}"
-		AdditionalIncludeDirectories="$self->{prefixincludes}src/include;src/include/port/win32;src/include/port/win32_msvc;$self->{includes}"
-		PreprocessorDefinitions="WIN32;_WINDOWS;__WINDOWS__;__WIN32__;EXEC_BACKEND;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self->{defines}$p->{defs}"
-		StringPooling="$p->{strpool}"
-		RuntimeLibrary="$p->{runtime}" DisableSpecificWarnings="$self->{disablewarnings}"
-		AdditionalOptions="/MP"
-EOF
-	print $f <<EOF;
-		AssemblerOutput="0" AssemblerListingLocation=".\\$cfgname\\$self->{name}\\" ObjectFile=".\\$cfgname\\$self->{name}\\"
-		ProgramDataBaseFileName=".\\$cfgname\\$self->{name}\\" BrowseInformation="0"
-		WarningLevel="3" SuppressStartupBanner="TRUE" DebugInformationFormat="3" CompileAs="0"/>
-	<Tool Name="VCLinkerTool" OutputFile=".\\$cfgname\\$self->{name}\\$self->{name}.$self->{type}"
-		AdditionalDependencies="$libs"
-		LinkIncremental="0" SuppressStartupBanner="TRUE" AdditionalLibraryDirectories="" IgnoreDefaultLibraryNames="libc"
-		StackReserveSize="4194304" DisableSpecificWarnings="$self->{disablewarnings}"
-		GenerateDebugInformation="TRUE" ProgramDatabaseFile=".\\$cfgname\\$self->{name}\\$self->{name}.pdb"
-		GenerateMapFile="FALSE" MapFileName=".\\$cfgname\\$self->{name}\\$self->{name}.map"
-		RandomizedBaseAddress="FALSE"
-		SubSystem="1" TargetMachine="$targetmachine"
-EOF
-	if ($self->{disablelinkerwarnings})
-	{
-		print $f
-		  "\t\tAdditionalOptions=\"/ignore:$self->{disablelinkerwarnings}\"\n";
-	}
-	if ($self->{implib})
-	{
-		my $l = $self->{implib};
-		$l =~ s/__CFGNAME__/$cfgname/g;
-		print $f "\t\tImportLibrary=\"$l\"\n";
-	}
-	if ($self->{def})
-	{
-		my $d = $self->{def};
-		$d =~ s/__CFGNAME__/$cfgname/g;
-		print $f "\t\tModuleDefinitionFile=\"$d\"\n";
-	}
-
-	print $f "\t/>\n";
-	print $f
-	  "\t<Tool Name=\"VCLibrarianTool\" OutputFile=\".\\$cfgname\\$self->{name}\\$self->{name}.lib\" IgnoreDefaultLibraryNames=\"libc\" />\n";
-	print $f
-	  "\t<Tool Name=\"VCResourceCompilerTool\" AdditionalIncludeDirectories=\"src\\include\" />\n";
-	if ($self->{builddef})
-	{
-		print $f
-		  "\t<Tool Name=\"VCPreLinkEventTool\" Description=\"Generate DEF file\" CommandLine=\"perl src\\tools\\msvc\\gendef.pl $cfgname\\$self->{name} $self->{platform}\" />\n";
-	}
-	print $f <<EOF;
-  </Configuration>
-EOF
-	return;
-}
-
-sub WriteReferences
-{
-	my ($self, $f) = @_;
-	print $f " <References>\n";
-	foreach my $ref (@{ $self->{references} })
-	{
-		print $f
-		  "  <ProjectReference ReferencedProjectIdentifier=\"$ref->{guid}\" Name=\"$ref->{name}\" />\n";
-	}
-	print $f " </References>\n";
-	return;
-}
-
-sub GenerateCustomTool
-{
-	my ($self, $desc, $tool, $output, $cfg) = @_;
-	if (!defined($cfg))
-	{
-		return $self->GenerateCustomTool($desc, $tool, $output, 'Debug')
-		  . $self->GenerateCustomTool($desc, $tool, $output, 'Release');
-	}
-	return
-	  "<FileConfiguration Name=\"$cfg|$self->{platform}\"><Tool Name=\"VCCustomBuildTool\" Description=\"$desc\" CommandLine=\"$tool\" AdditionalDependencies=\"\" Outputs=\"$output\" /></FileConfiguration>";
-}
-
-package VC2005Project;
-
-#
-# Package that encapsulates a Visual C++ 2005 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver} = '8.00';
-
-	return $self;
-}
-
-package VC2008Project;
-
-#
-# Package that encapsulates a Visual C++ 2008 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver} = '9.00';
-
-	return $self;
-}
-
-1;
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 92a4fb6841f..1a94cd866ee 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -13,7 +13,6 @@ use warnings;
 use Exporter;
 use Project;
 use Solution;
-use VCBuildProject;
 use MSBuildProject;
 
 our (@ISA, @EXPORT);
@@ -31,23 +30,7 @@ sub CreateSolution
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '8.00')
-	{
-		return new VS2005Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '9.00')
-	{
-		return new VS2008Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '10.00')
-	{
-		return new VS2010Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '11.00')
-	{
-		return new VS2012Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '12.00')
+	if ($visualStudioVersion eq '12.00')
 	{
 		return new VS2013Solution(@_);
 	}
@@ -78,23 +61,7 @@ sub CreateProject
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '8.00')
-	{
-		return new VC2005Project(@_);
-	}
-	elsif ($visualStudioVersion eq '9.00')
-	{
-		return new VC2008Project(@_);
-	}
-	elsif ($visualStudioVersion eq '10.00')
-	{
-		return new VC2010Project(@_);
-	}
-	elsif ($visualStudioVersion eq '11.00')
-	{
-		return new VC2012Project(@_);
-	}
-	elsif ($visualStudioVersion eq '12.00')
+	if ($visualStudioVersion eq '12.00')
 	{
 		return new VC2013Project(@_);
 	}
-- 
2.18.0.rc2.dirty

v1-0003-Introduce-minimal-C99-usage-to-verify-compiler-su.patchtext/x-diff; charset=us-asciiDownload
From e0a39e6ecd0542ee8274351e2e3ed3655b85f15f Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:44:33 -0700
Subject: [PATCH v1 3/4] Introduce minimal C99 usage to verify compiler
 support.

This just converts a few for loops in postgres.c to declare variables
in the loop initializer, and uses designated initializers in smgr.c's
definition of smgr callbacks.

Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
 src/backend/storage/smgr/smgr.c | 21 ++++++++++++++++++---
 src/backend/tcop/postgres.c     | 25 +++++++------------------
 2 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/src/backend/storage/smgr/smgr.c b/src/backend/storage/smgr/smgr.c
index 08f06bade25..189342ef86a 100644
--- a/src/backend/storage/smgr/smgr.c
+++ b/src/backend/storage/smgr/smgr.c
@@ -67,9 +67,24 @@ typedef struct f_smgr
 
 static const f_smgr smgrsw[] = {
 	/* magnetic disk */
-	{mdinit, NULL, mdclose, mdcreate, mdexists, mdunlink, mdextend,
-		mdprefetch, mdread, mdwrite, mdwriteback, mdnblocks, mdtruncate,
-		mdimmedsync, mdpreckpt, mdsync, mdpostckpt
+	{
+		.smgr_init = mdinit,
+		.smgr_shutdown = NULL,
+		.smgr_close = mdclose,
+		.smgr_create = mdcreate,
+		.smgr_exists = mdexists,
+		.smgr_unlink = mdunlink,
+		.smgr_extend = mdextend,
+		.smgr_prefetch = mdprefetch,
+		.smgr_read = mdread,
+		.smgr_write = mdwrite,
+		.smgr_writeback = mdwriteback,
+		.smgr_nblocks = mdnblocks,
+		.smgr_truncate = mdtruncate,
+		.smgr_immedsync = mdimmedsync,
+		.smgr_pre_ckpt = mdpreckpt,
+		.smgr_sync = mdsync,
+		.smgr_post_ckpt = mdpostckpt
 	}
 };
 
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 07b956553a7..7a9ada2c719 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -1310,7 +1310,6 @@ exec_parse_message(const char *query_string,	/* string to execute */
 	{
 		Query	   *query;
 		bool		snapshot_set = false;
-		int			i;
 
 		raw_parse_tree = linitial_node(RawStmt, parsetree_list);
 
@@ -1366,7 +1365,7 @@ exec_parse_message(const char *query_string,	/* string to execute */
 		/*
 		 * Check all parameter types got determined.
 		 */
-		for (i = 0; i < numParams; i++)
+		for (int i = 0; i < numParams; i++)
 		{
 			Oid			ptype = paramTypes[i];
 
@@ -1555,10 +1554,8 @@ exec_bind_message(StringInfo input_message)
 	numPFormats = pq_getmsgint(input_message, 2);
 	if (numPFormats > 0)
 	{
-		int			i;
-
 		pformats = (int16 *) palloc(numPFormats * sizeof(int16));
-		for (i = 0; i < numPFormats; i++)
+		for (int i = 0; i < numPFormats; i++)
 			pformats[i] = pq_getmsgint(input_message, 2);
 	}
 
@@ -1641,8 +1638,6 @@ exec_bind_message(StringInfo input_message)
 	 */
 	if (numParams > 0)
 	{
-		int			paramno;
-
 		params = (ParamListInfo) palloc(offsetof(ParamListInfoData, params) +
 										numParams * sizeof(ParamExternData));
 		/* we have static list of params, so no hooks needed */
@@ -1654,7 +1649,7 @@ exec_bind_message(StringInfo input_message)
 		params->parserSetupArg = NULL;
 		params->numParams = numParams;
 
-		for (paramno = 0; paramno < numParams; paramno++)
+		for (int paramno = 0; paramno < numParams; paramno++)
 		{
 			Oid			ptype = psrc->param_types[paramno];
 			int32		plength;
@@ -1782,10 +1777,8 @@ exec_bind_message(StringInfo input_message)
 	numRFormats = pq_getmsgint(input_message, 2);
 	if (numRFormats > 0)
 	{
-		int			i;
-
 		rformats = (int16 *) palloc(numRFormats * sizeof(int16));
-		for (i = 0; i < numRFormats; i++)
+		for (int i = 0; i < numRFormats; i++)
 			rformats[i] = pq_getmsgint(input_message, 2);
 	}
 
@@ -2212,7 +2205,6 @@ errdetail_params(ParamListInfo params)
 	{
 		StringInfoData param_str;
 		MemoryContext oldcontext;
-		int			paramno;
 
 		/* This code doesn't support dynamic param lists */
 		Assert(params->paramFetch == NULL);
@@ -2222,7 +2214,7 @@ errdetail_params(ParamListInfo params)
 
 		initStringInfo(&param_str);
 
-		for (paramno = 0; paramno < params->numParams; paramno++)
+		for (int paramno = 0; paramno < params->numParams; paramno++)
 		{
 			ParamExternData *prm = &params->params[paramno];
 			Oid			typoutput;
@@ -2325,7 +2317,6 @@ static void
 exec_describe_statement_message(const char *stmt_name)
 {
 	CachedPlanSource *psrc;
-	int			i;
 
 	/*
 	 * Start up a transaction command. (Note that this will normally change
@@ -2384,7 +2375,7 @@ exec_describe_statement_message(const char *stmt_name)
 														 * message type */
 	pq_sendint16(&row_description_buf, psrc->num_params);
 
-	for (i = 0; i < psrc->num_params; i++)
+	for (int i = 0; i < psrc->num_params; i++)
 	{
 		Oid			ptype = psrc->param_types[i];
 
@@ -4179,10 +4170,8 @@ PostgresMain(int argc, char *argv[],
 					numParams = pq_getmsgint(&input_message, 2);
 					if (numParams > 0)
 					{
-						int			i;
-
 						paramTypes = (Oid *) palloc(numParams * sizeof(Oid));
-						for (i = 0; i < numParams; i++)
+						for (int i = 0; i < numParams; i++)
 							paramTypes[i] = pq_getmsgint(&input_message, 4);
 					}
 					pq_getmsgend(&input_message);
-- 
2.18.0.rc2.dirty

v1-0004-robot-Add-CI-control-files.patchtext/x-diff; charset=us-asciiDownload
From 1905cc80e205f390cdc7acfe79293dce969eed68 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:18:59 -0700
Subject: [PATCH v1 4/4] [robot] Add CI control files

This commit adds control files to trigger building and testing.  It is not
part of the patch set.
---
 .travis.yml   | 34 ++++++++++++++++++++++++++++++++++
 README.md     | 21 +++++++++++++++++++++
 appveyor.yml  | 27 +++++++++++++++++++++++++++
 buildsetup.pl | 38 ++++++++++++++++++++++++++++++++++++++
 dumpregr.pl   | 20 ++++++++++++++++++++
 5 files changed, 140 insertions(+)
 create mode 100644 .travis.yml
 create mode 100644 README.md
 create mode 100644 appveyor.yml
 create mode 100644 buildsetup.pl
 create mode 100644 dumpregr.pl

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 00000000000..08ef1fbf9a0
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,34 @@
+sudo: required
+addons:
+  apt:
+    packages:
+      - gdb
+      - lcov
+      - libipc-run-perl
+      - libperl-dev
+      - libpython-dev
+      - tcl-dev
+      - libldap2-dev
+      - libicu-dev
+      - docbook
+      - docbook-dsssl
+      - docbook-xsl
+      - libxml2-utils
+      - openjade1.3
+      - opensp
+      - xsltproc
+language: c
+cache: ccache
+before_install:
+  - echo '/tmp/%e-%s-%p.core' | sudo tee /proc/sys/kernel/core_pattern
+script: ./configure --enable-debug --enable-cassert --enable-coverage --enable-tap-tests --with-tcl --with-python --with-perl --with-ldap --with-icu && make -j4 all contrib docs && make check-world
+#after_success:
+#  - bash <(curl -s https://codecov.io/bash)
+after_failure:
+  - for f in $(find . -name regression.diffs) ; do echo "========= Contents of $f" ; head -1000 $f ; done
+  - |
+    for corefile in $(find /tmp/ -name '*.core' 2>/dev/null) ; do
+      binary=$(gdb -quiet -core $corefile -batch -ex 'info auxv' | grep AT_EXECFN | perl -pe "s/^.*\"(.*)\"\$/\$1/g")
+      echo dumping $corefile for $binary
+      gdb --batch --quiet -ex "thread apply all bt full" -ex "quit" $binary $corefile
+    done
diff --git a/README.md b/README.md
new file mode 100644
index 00000000000..81e7b3c27ad
--- /dev/null
+++ b/README.md
@@ -0,0 +1,21 @@
+Zheap Part I: Undo Log Storage
+
+This branch is maintained by a robot.  It is automatically filtered and
+combined from the commit history in the zheap-tmunro branch at
+at https://github.com/EnterpriseDB/zheap into a more presentable form.
+It's a preview of the lowest level patch-set in the Zheap proposal.
+It's work in progress.
+
+There are five patches in this patch set:
+
+* [0001-Add-undo-log-manager.patch](../../commit/417481eaf562a36808cc7dbdbffbdef0361eff4f)
+* [0002-Provide-access-to-undo-log-data-via-the-buffer-manager.patch](../../commit/88ce7dcbf20f243649aea1bd0ca3f42c7e0cc129)
+* [0003-Add-developer-documentation-for-the-undo-log-manager.patch](../../commit/0c741fec6ffa4e69436a7e38dabc85b388477297)
+* [0004-Add-tests-for-the-undo-log-manager.patch](../../commit/5d44b81eab636cb7f002704ca685af8a2800024b)
+* [0005-Add-user-facing-documentation-for-undo-logs.patch](../../commit/892e5202b1c45a3f2032d4bef671413268738348)
+
+This branch is automatically tested by:
+
+* Ubuntu build bot over at Travis CI:  [<img src="https://travis-ci.org/macdice/postgres.svg?branch=undo-log-storage"/>](https://travis-ci.org/macdice/postgres/branches)
+* Windows build bot over at AppVeyor: [<img src="https://ci.appveyor.com/api/projects/status/github/macdice?branch=undo-log-storage&svg=true"/>](https://ci.appveyor.com/project/macdice/postgres/branch/undo-log-storage)
+
diff --git a/appveyor.yml b/appveyor.yml
new file mode 100644
index 00000000000..af1ce3da32a
--- /dev/null
+++ b/appveyor.yml
@@ -0,0 +1,27 @@
+#  appveyor.yml
+install:
+  - cinst winflexbison
+  - '"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64'
+  - '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86_amd64'
+
+
+before_build:
+  - rename c:\ProgramData\chocolatey\bin\win_flex.exe flex.exe
+  - rename c:\ProgramData\chocolatey\bin\win_bison.exe bison.exe
+  - perl buildsetup.pl
+
+build:
+  project: pgsql.sln
+
+before_test:
+  - 'perl -p -i.bak -e "s/^test: tablespace/#test: tablespace/" src/test/regress/serial_schedule'
+  - 'perl -p -i.bak -e "s/^test: tablespace/#test: tablespace/" src/test/regress/parallel_schedule'
+
+test_script:
+  - cd src\tools\msvc && vcregress check
+
+on_failure:
+  - perl dumpregr.pl
+
+configuration:
+  - Release
diff --git a/buildsetup.pl b/buildsetup.pl
new file mode 100644
index 00000000000..23df2fb1aa4
--- /dev/null
+++ b/buildsetup.pl
@@ -0,0 +1,38 @@
+# first part of postgres build.pl, just doesn't run msbuild
+
+use strict;
+
+BEGIN
+{
+
+    chdir("../../..") if (-d "../msvc" && -d "../../../src");
+
+}
+
+use lib "src/tools/msvc";
+
+use Cwd;
+
+use Mkvcbuild;
+
+# buildenv.pl is for specifying the build environment settings
+# it should contain lines like:
+# $ENV{PATH} = "c:/path/to/bison/bin;$ENV{PATH}";
+
+if (-e "src/tools/msvc/buildenv.pl")
+{
+    do "src/tools/msvc/buildenv.pl";
+}
+elsif (-e "./buildenv.pl")
+{
+    do "./buildenv.pl";
+}
+
+# set up the project
+our $config;
+do "config_default.pl";
+do "config.pl" if (-f "src/tools/msvc/config.pl");
+
+# print "PATH: $_\n" foreach (split(';',$ENV{PATH}));
+
+Mkvcbuild::mkvcbuild($config);
diff --git a/dumpregr.pl b/dumpregr.pl
new file mode 100644
index 00000000000..d9039da7844
--- /dev/null
+++ b/dumpregr.pl
@@ -0,0 +1,20 @@
+use strict;
+use warnings FATAL => qw(all);
+
+use File::Find;
+
+my $Target = "regression.diffs";
+
+find(\&dump, "src");
+
+sub dump {
+  if ($_ eq $Target) {
+    my $path = $File::Find::name;
+    print "=== $path ===\n";
+    open(my $fh, "<", $_) || die "wtf";
+    while (my $line = <$fh>) {
+      print $line;
+      if ($. > 1000) { last; }
+    }
+  }
+}
-- 
2.18.0.rc2.dirty

#76Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#75)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Andres Freund <andres@anarazel.de> writes:

There's a few further potential cleanups due to relying on c99:
- Use __func__ unconditionally, rather than having configure test for it
- Use inline unconditionally, rather than having configure test for it
- Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
AC_TYPE_LONG_LONG_INT, we can rely on them being present.
- probably more in that vein

I wouldn't be in too much of a hurry to do that, particularly not the
third item. You are confusing "compiler is c99" with "system headers
are c99". Moreover, I don't see that we're buying much with such
changes.

regards, tom lane

#77Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#76)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-22 20:16:24 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

There's a few further potential cleanups due to relying on c99:
- Use __func__ unconditionally, rather than having configure test for it
- Use inline unconditionally, rather than having configure test for it
- Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
AC_TYPE_LONG_LONG_INT, we can rely on them being present.
- probably more in that vein

I wouldn't be in too much of a hurry to do that, particularly not the
third item. You are confusing "compiler is c99" with "system headers
are c99". Moreover, I don't see that we're buying much with such
changes.

Yea, I am not in much of a hurry on any of them. I think the only
argument for them is that it'd buy us a littlebit of a reduction in
configure runtime...

Greetings,

Andres Freund

#78Andres Freund
andres@anarazel.de
In reply to: Andres Freund (#75)
3 attachment(s)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 2018-08-22 17:09:05 -0700, Andres Freund wrote:

Attached is a version doing so.

Mildly updated version attached. This adds an explanatory commit
message, removes one stray docs C89 reference, and fixes a mis-squashing
of a patch.

Greetings,

Andres Freund

Attachments:

v2-0001-Require-C99-and-thus-MSCV-2013-upwards.patchtext/x-diff; charset=us-asciiDownload
From 4b63f3307180a778018439ad3dee9a89aa4f4352 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 15:10:23 -0700
Subject: [PATCH v2 1/4] Require C99 (and thus MSCV 2013 upwards).

In 86d78ef50e01 I enabled configure to check for C99 support, with the
goal of checking which platforms support C99.  While there are a few
machines without C99 support, de-supporting them for v12 was deemed
acceptable.

While not tested in aforementioned commit, the biggest increase in
minimum version comes from MSVC, which gained C99 support fairly
late. The subset in MSVC 2013 is sufficient for our needs, at this
point.  While that is a significant increase in minimum version, the
existing windows binaries are already built with a new enough version.

Make configure error out if C99 support could not be detected. For
MSVC builds, increase the minimum version to 2013.

The increase to MSVC 2013 allows us to get rid of VCBuildProject.pm,
as that was only required for MSVC 2005/2008.

Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
 configure                         |  49 +++++
 configure.in                      |  10 +
 doc/src/sgml/install-windows.sgml |  26 +--
 doc/src/sgml/installation.sgml    |   2 +-
 doc/src/sgml/sources.sgml         |  33 ++--
 src/tools/msvc/MSBuildProject.pm  |  78 +-------
 src/tools/msvc/README             |  18 +-
 src/tools/msvc/Solution.pm        | 102 ----------
 src/tools/msvc/VCBuildProject.pm  | 309 ------------------------------
 src/tools/msvc/VSObjectFactory.pm |  37 +---
 src/tools/msvc/build.pl           |   6 +-
 11 files changed, 112 insertions(+), 558 deletions(-)
 delete mode 100644 src/tools/msvc/VCBuildProject.pm

diff --git a/configure b/configure
index 836d68dad37..dd439ddd2f6 100755
--- a/configure
+++ b/configure
@@ -4602,6 +4602,13 @@ if test "x$ac_cv_prog_cc_c99" != xno; then :
 fi
 
 
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+    as_fn_error $? "C compiler \"$CC\" does not support C99" "$LINENO" 5
+fi
+
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
 ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
@@ -5361,6 +5368,48 @@ fi
 
 
   # -Wdeclaration-after-statement isn't applicable for C++
+  # Really don't want VLAs to be used in our dialect of C
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Werror=vla, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -Werror=vla, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__Werror_vla+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -Werror=vla"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  pgac_cv_prog_CC_cflags__Werror_vla=yes
+else
+  pgac_cv_prog_CC_cflags__Werror_vla=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__Werror_vla" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__Werror_vla" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__Werror_vla" = x"yes"; then
+  CFLAGS="${CFLAGS} -Werror=vla"
+fi
+
+
+  # -Wvla is not applicable for C++
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Wendif-labels, for CFLAGS" >&5
 $as_echo_n "checking whether ${CC} supports -Wendif-labels, for CFLAGS... " >&6; }
diff --git a/configure.in b/configure.in
index 6e141064e5c..5869ab7c5bc 100644
--- a/configure.in
+++ b/configure.in
@@ -359,6 +359,13 @@ esac
 
 AC_PROG_CC([$pgac_cc_list])
 AC_PROG_CC_C99()
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+    AC_MSG_ERROR([C compiler "$CC" does not support C99])
+fi
+
 AC_PROG_CXX([$pgac_cxx_list])
 
 # Check if it's Intel's compiler, which (usually) pretends to be gcc,
@@ -477,6 +484,9 @@ if test "$GCC" = yes -a "$ICC" = no; then
   # These work in some but not all gcc versions
   PGAC_PROG_CC_CFLAGS_OPT([-Wdeclaration-after-statement])
   # -Wdeclaration-after-statement isn't applicable for C++
+  # Really don't want VLAs to be used in our dialect of C
+  PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])
+  # -Wvla is not applicable for C++
   PGAC_PROG_CC_CFLAGS_OPT([-Wendif-labels])
   PGAC_PROG_CXX_CFLAGS_OPT([-Wendif-labels])
   PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 9597bc35a14..22a2ffd55ee 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -22,7 +22,7 @@
   Microsoft tools is to install <productname>Visual Studio Express 2017
   for Windows Desktop</productname> and use the included
   compiler. It is also possible to build with the full
-  <productname>Microsoft Visual C++ 2005 to 2017</productname>.
+  <productname>Microsoft Visual C++ 2013 to 2017</productname>.
   In some cases that requires the installation of the
   <productname>Windows SDK</productname> in addition to the compiler.
  </para>
@@ -77,20 +77,24 @@
  <para>
   Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
   32-bit PostgreSQL builds are possible with
-  <productname>Visual Studio 2005</productname> to
+  <productname>Visual Studio 2013</productname> to
   <productname>Visual Studio 2017</productname> (including Express editions),
   as well as standalone Windows SDK releases 6.0 to 8.1.
   64-bit PostgreSQL builds are supported with
   <productname>Microsoft Windows SDK</productname> version 6.0a to 8.1 or
-  <productname>Visual Studio 2008</productname> and above. Compilation
-  is supported down to <productname>Windows XP</productname> and
-  <productname>Windows Server 2003</productname> when building with
-  <productname>Visual Studio 2005</productname> to
-  <productname>Visual Studio 2013</productname>. Building with
-  <productname>Visual Studio 2015</productname> is supported down to
-  <productname>Windows Vista</productname> and <productname>Windows Server 2008</productname>.
-   Building with <productname>Visual Studio 2017</productname> is supported
-   down to <productname>Windows 7 SP1</productname> and <productname>Windows Server 2008 R2 SP1</productname>.
+  <productname>Visual Studio 2013</productname> and above. Compilation
+  is supported down to <productname>Windows 7</productname> and
+  <productname>Windows Server 2008 R2 SP1</productname> when building with
+  <productname>Visual Studio 2013</productname> to
+  <productname>Visual Studio 2017</productname>.
+   <!--
+       For 2013 requirements:
+       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
+       For 2015 requirements:
+       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
+       For 2017 requirements:
+       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
+   -->
  </para>
 
  <para>
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 10c925d2905..4487d0cfd17 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -85,7 +85,7 @@ su - postgres
     <listitem>
      <para>
       You need an <acronym>ISO</acronym>/<acronym>ANSI</acronym> C compiler (at least
-      C89-compliant). Recent
+      C99-compliant). Recent
       versions of <productname>GCC</productname> are recommended, but
       <productname>PostgreSQL</productname> is known to build using a wide variety
       of compilers from different vendors.
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
index e53ee1dc6ad..419f753c7bc 100644
--- a/doc/src/sgml/sources.sgml
+++ b/doc/src/sgml/sources.sgml
@@ -867,19 +867,30 @@ BETTER: unrecognized node type: 42
     <title>C Standard</title>
     <para>
      Code in <productname>PostgreSQL</productname> should only rely on language
-     features available in the C89 standard. That means a conforming
-     C89 compiler has to be able to compile postgres, at least aside
-     from a few platform dependent pieces. Features from later
-     revision of the C standard or compiler specific features can be
-     used, if a fallback is provided.
+     features available in the C99 standard. That means a conforming
+     C99 compiler has to be able to compile postgres, at least aside
+     from a few platform dependent pieces.
     </para>
     <para>
-     For example <literal>static inline</literal> and
-     <literal>_StaticAssert()</literal> are currently used, even
-     though they are from newer revisions of the C standard. If not
-     available we respectively fall back to defining the functions
-     without inline, and to using a C89 compatible replacement that
-     performs the same checks, but emits rather cryptic messages.
+     A few features included in the C99 standard are, at this time, not be
+     permitted to be used in core <productname>PostgreSQL</productname>
+     code. This currently includes variable length arrays, intermingled
+     declarations and code, <literal>//</literal> comments, universal
+     character names. Reasons for that include portability and historical
+     practices.
+    </para>
+    <para>
+     Features from later revision of the C standard or compiler specific
+     features can be used, if a fallback is provided.
+    </para>
+    <para>
+     For example <literal>_StaticAssert()</literal> and
+     <literal>__builtin_constant_p</literal> are currently used, even though
+     they are from newer revisions of the C standard and a
+     <productname>GCC</productname> extension respectively. If not available
+     we respectively fall back to using a C99 compatible replacement that
+     performs the same checks, but emits rather cryptic messages and do not
+     use <literal>__builtin_constant_p</literal>.
     </para>
    </simplesect>
 
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index 47252533a1b..149213378cf 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -1,7 +1,7 @@
 package MSBuildProject;
 
 #
-# Package that encapsulates a MSBuild project file (Visual C++ 2010 or greater)
+# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
 #
 # src/tools/msvc/MSBuildProject.pm
 #
@@ -257,6 +257,7 @@ sub WriteConfigurationPropertyGroup
     <UseOfMfc>false</UseOfMfc>
     <CharacterSet>MultiByte</CharacterSet>
     <WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
+    <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
   </PropertyGroup>
 EOF
 	return;
@@ -391,75 +392,6 @@ EOF
 	return;
 }
 
-package VC2010Project;
-
-#
-# Package that encapsulates a Visual C++ 2010 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver} = '10.00';
-
-	return $self;
-}
-
-package VC2012Project;
-
-#
-# Package that encapsulates a Visual C++ 2012 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver}           = '11.00';
-	$self->{PlatformToolset} = 'v110';
-
-	return $self;
-}
-
-# This override adds the <PlatformToolset> element
-# to the PropertyGroup labeled "Configuration"
-sub WriteConfigurationPropertyGroup
-{
-	my ($self, $f, $cfgname, $p) = @_;
-	my $cfgtype =
-	  ($self->{type} eq "exe")
-	  ? 'Application'
-	  : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary');
-
-	print $f <<EOF;
-  <PropertyGroup Condition="'\$(Configuration)|\$(Platform)'=='$cfgname|$self->{platform}'" Label="Configuration">
-    <ConfigurationType>$cfgtype</ConfigurationType>
-    <UseOfMfc>false</UseOfMfc>
-    <CharacterSet>MultiByte</CharacterSet>
-    <WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
-    <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
-  </PropertyGroup>
-EOF
-	return;
-}
-
 package VC2013Project;
 
 #
@@ -468,7 +400,7 @@ package VC2013Project;
 
 use strict;
 use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
 
 no warnings qw(redefine);    ## no critic
 
@@ -493,7 +425,7 @@ package VC2015Project;
 
 use strict;
 use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
 
 no warnings qw(redefine);    ## no critic
 
@@ -518,7 +450,7 @@ package VC2017Project;
 
 use strict;
 use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
 
 no warnings qw(redefine);    ## no critic
 
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index bfa98045f22..4ab81d3402f 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
 ==========
 
 This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2005 - 2017. This builds the whole backend, not just
+Microsoft Visual Studio 2013 - 2017. This builds the whole backend, not just
 the libpq frontend library. For more information, see the documentation
 chapter "Installation on Windows" and the description below.
 
@@ -67,14 +67,12 @@ Install.pm             module containing the install logic
 Mkvcbuild.pm           module containing the code to generate the Visual
                        Studio build (project/solution) files
 MSBuildProject.pm      module containing the code to generate MSBuild based
-                       project files (Visual Studio 2010 or greater)
+                       project files (Visual Studio 2013 or greater)
 Project.pm             module containing the common code to generate the
                        Visual Studio project files. Also provides the
                        common interface of all project file generators
 Solution.pm            module containing the code to generate the Visual
                        Studio solution files.
-VCBuildProject.pm      module containing the code to generate VCBuild based
-                       project files (Visual Studio 2005/2008)
 VSObjectFactory.pm     factory module providing the code to create the
                        appropriate project/solution files for the current
                        environment
@@ -90,14 +88,12 @@ config_default.pl to create the configuration arguments.
 These configuration arguments are passed over to Mkvcbuild::mkvcbuild
 (Mkvcbuild.pm) which creates the Visual Studio project and solution files.
 It does this by using VSObjectFactory::CreateSolution to create an object
-implementing the Solution interface (this could be either a VS2005Solution,
-a VS2008Solution, a VS2010Solution or a VS2012Solution or a VS2013Solution,
+implementing the Solution interface (this could be either a VS2013Solution,
 or a VS2015Solution or a VS2017Solution, all in Solution.pm, depending on
 the user's build environment) and adding objects implementing the corresponding
-Project interface (VC2005Project or VC2008Project from VCBuildProject.pm or
-VC2010Project or VC2012Project or VC2013Project or VC2015Project or VC2017Project
-from MSBuildProject.pm) to it.
+Project interface (VC2013Project or VC2015Project or VC2017Project from
+MSBuildProject.pm) to it.
 When Solution::Save is called, the implementations of Solution and Project
 save their content in the appropriate format.
-The final step of starting the appropriate build program (msbuild or vcbuild)
-is performed in build.pl again.
+The final step of starting the appropriate build program (msbuild) is
+performed in build.pl again.
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 78db247b291..7d7ce8b0312 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -760,108 +760,6 @@ sub GetFakeConfigure
 	return $cfg;
 }
 
-package VS2005Solution;
-
-#
-# Package that encapsulates a Visual Studio 2005 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '9.00';
-	$self->{vcver}               = '8.00';
-	$self->{visualStudioName}    = 'Visual Studio 2005';
-
-	return $self;
-}
-
-package VS2008Solution;
-
-#
-# Package that encapsulates a Visual Studio 2008 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '10.00';
-	$self->{vcver}               = '9.00';
-	$self->{visualStudioName}    = 'Visual Studio 2008';
-
-	return $self;
-}
-
-package VS2010Solution;
-
-#
-# Package that encapsulates a Visual Studio 2010 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '11.00';
-	$self->{vcver}               = '10.00';
-	$self->{visualStudioName}    = 'Visual Studio 2010';
-
-	return $self;
-}
-
-package VS2012Solution;
-
-#
-# Package that encapsulates a Visual Studio 2012 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion} = '12.00';
-	$self->{vcver}               = '11.00';
-	$self->{visualStudioName}    = 'Visual Studio 2012';
-
-	return $self;
-}
-
 package VS2013Solution;
 
 #
diff --git a/src/tools/msvc/VCBuildProject.pm b/src/tools/msvc/VCBuildProject.pm
deleted file mode 100644
index 6cdf822a637..00000000000
--- a/src/tools/msvc/VCBuildProject.pm
+++ /dev/null
@@ -1,309 +0,0 @@
-package VCBuildProject;
-
-#
-# Package that encapsulates a VCBuild (Visual C++ 2005/2008) project file
-#
-# src/tools/msvc/VCBuildProject.pm
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Project);
-
-no warnings qw(redefine);    ## no critic
-
-sub _new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{filenameExtension} = '.vcproj';
-
-	return $self;
-}
-
-sub WriteHeader
-{
-	my ($self, $f) = @_;
-
-	print $f <<EOF;
-<?xml version="1.0" encoding="Windows-1252"?>
-<VisualStudioProject ProjectType="Visual C++" Version="$self->{vcver}" Name="$self->{name}" ProjectGUID="$self->{guid}">
- <Platforms><Platform Name="$self->{platform}"/></Platforms>
- <Configurations>
-EOF
-
-	$self->WriteConfiguration(
-		$f, 'Debug',
-		{
-			defs     => "_DEBUG;DEBUG=1",
-			wholeopt => 0,
-			opt      => 0,
-			strpool  => 'false',
-			runtime  => 3
-		});
-	$self->WriteConfiguration(
-		$f,
-		'Release',
-		{
-			defs     => "",
-			wholeopt => 0,
-			opt      => 3,
-			strpool  => 'true',
-			runtime  => 2
-		});
-	print $f <<EOF;
- </Configurations>
-EOF
-	$self->WriteReferences($f);
-	return;
-}
-
-sub WriteFiles
-{
-	my ($self, $f) = @_;
-	print $f <<EOF;
- <Files>
-EOF
-	my @dirstack = ();
-	my %uniquefiles;
-	foreach my $fileNameWithPath (sort keys %{ $self->{files} })
-	{
-		confess "Bad format filename '$fileNameWithPath'\n"
-		  unless ($fileNameWithPath =~ m!^(.*)/([^/]+)\.(c|cpp|y|l|rc)$!);
-		my $dir  = $1;
-		my $file = $2;
-
-		# Walk backwards down the directory stack and close any dirs
-		# we're done with.
-		while ($#dirstack >= 0)
-		{
-			if (join('/', @dirstack) eq
-				substr($dir, 0, length(join('/', @dirstack))))
-			{
-				last if (length($dir) == length(join('/', @dirstack)));
-				last
-				  if (substr($dir, length(join('/', @dirstack)), 1) eq '/');
-			}
-			print $f ' ' x $#dirstack . "  </Filter>\n";
-			pop @dirstack;
-		}
-
-		# Now walk forwards and create whatever directories are needed
-		while (join('/', @dirstack) ne $dir)
-		{
-			my $left = substr($dir, length(join('/', @dirstack)));
-			$left =~ s/^\///;
-			my @pieces = split /\//, $left;
-			push @dirstack, $pieces[0];
-			print $f ' ' x $#dirstack
-			  . "  <Filter Name=\"$pieces[0]\" Filter=\"\">\n";
-		}
-
-		# VC builds do not like file paths with forward slashes.
-		my $fileNameWithPathFormatted = $fileNameWithPath;
-		$fileNameWithPathFormatted =~ s/\//\\/g;
-
-		print $f ' ' x $#dirstack
-		  . "   <File RelativePath=\"$fileNameWithPathFormatted\"";
-		if ($fileNameWithPath =~ /\.y$/)
-		{
-			my $of = $fileNameWithPath;
-			$of =~ s/\.y$/.c/;
-			$of =~
-			  s{^src/pl/plpgsql/src/gram.c$}{src/pl/plpgsql/src/pl_gram.c};
-			print $f '>'
-			  . $self->GenerateCustomTool(
-				'Running bison on ' . $fileNameWithPath,
-				"perl src/tools/msvc/pgbison.pl $fileNameWithPath", $of)
-			  . '</File>' . "\n";
-		}
-		elsif ($fileNameWithPath =~ /\.l$/)
-		{
-			my $of = $fileNameWithPath;
-			$of =~ s/\.l$/.c/;
-			print $f '>'
-			  . $self->GenerateCustomTool(
-				'Running flex on ' . $fileNameWithPath,
-				"perl src/tools/msvc/pgflex.pl $fileNameWithPath", $of)
-			  . '</File>' . "\n";
-		}
-		elsif (defined($uniquefiles{$file}))
-		{
-
-			# File already exists, so fake a new name
-			my $obj = $dir;
-			$obj =~ s!/!_!g;
-			print $f
-			  "><FileConfiguration Name=\"Debug|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\debug\\$self->{name}\\$obj"
-			  . "_$file.obj\" /></FileConfiguration><FileConfiguration Name=\"Release|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\release\\$self->{name}\\$obj"
-			  . "_$file.obj\" /></FileConfiguration></File>\n";
-		}
-		else
-		{
-			$uniquefiles{$file} = 1;
-			print $f " />\n";
-		}
-	}
-	while ($#dirstack >= 0)
-	{
-		print $f ' ' x $#dirstack . "  </Filter>\n";
-		pop @dirstack;
-	}
-	print $f <<EOF;
- </Files>
-EOF
-	return;
-}
-
-sub Footer
-{
-	my ($self, $f) = @_;
-
-	print $f <<EOF;
- <Globals/>
-</VisualStudioProject>
-EOF
-	return;
-}
-
-sub WriteConfiguration
-{
-	my ($self, $f, $cfgname, $p) = @_;
-	my $cfgtype =
-	  ($self->{type} eq "exe") ? 1 : ($self->{type} eq "dll" ? 2 : 4);
-	my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ' ');
-
-	my $targetmachine = $self->{platform} eq 'Win32' ? 1 : 17;
-
-	print $f <<EOF;
-  <Configuration Name="$cfgname|$self->{platform}" OutputDirectory=".\\$cfgname\\$self->{name}" IntermediateDirectory=".\\$cfgname\\$self->{name}"
-	ConfigurationType="$cfgtype" UseOfMFC="0" ATLMinimizesCRunTimeLibraryUsage="FALSE" CharacterSet="2" WholeProgramOptimization="$p->{wholeopt}">
-	<Tool Name="VCCLCompilerTool" Optimization="$p->{opt}"
-		AdditionalIncludeDirectories="$self->{prefixincludes}src/include;src/include/port/win32;src/include/port/win32_msvc;$self->{includes}"
-		PreprocessorDefinitions="WIN32;_WINDOWS;__WINDOWS__;__WIN32__;EXEC_BACKEND;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self->{defines}$p->{defs}"
-		StringPooling="$p->{strpool}"
-		RuntimeLibrary="$p->{runtime}" DisableSpecificWarnings="$self->{disablewarnings}"
-		AdditionalOptions="/MP"
-EOF
-	print $f <<EOF;
-		AssemblerOutput="0" AssemblerListingLocation=".\\$cfgname\\$self->{name}\\" ObjectFile=".\\$cfgname\\$self->{name}\\"
-		ProgramDataBaseFileName=".\\$cfgname\\$self->{name}\\" BrowseInformation="0"
-		WarningLevel="3" SuppressStartupBanner="TRUE" DebugInformationFormat="3" CompileAs="0"/>
-	<Tool Name="VCLinkerTool" OutputFile=".\\$cfgname\\$self->{name}\\$self->{name}.$self->{type}"
-		AdditionalDependencies="$libs"
-		LinkIncremental="0" SuppressStartupBanner="TRUE" AdditionalLibraryDirectories="" IgnoreDefaultLibraryNames="libc"
-		StackReserveSize="4194304" DisableSpecificWarnings="$self->{disablewarnings}"
-		GenerateDebugInformation="TRUE" ProgramDatabaseFile=".\\$cfgname\\$self->{name}\\$self->{name}.pdb"
-		GenerateMapFile="FALSE" MapFileName=".\\$cfgname\\$self->{name}\\$self->{name}.map"
-		RandomizedBaseAddress="FALSE"
-		SubSystem="1" TargetMachine="$targetmachine"
-EOF
-	if ($self->{disablelinkerwarnings})
-	{
-		print $f
-		  "\t\tAdditionalOptions=\"/ignore:$self->{disablelinkerwarnings}\"\n";
-	}
-	if ($self->{implib})
-	{
-		my $l = $self->{implib};
-		$l =~ s/__CFGNAME__/$cfgname/g;
-		print $f "\t\tImportLibrary=\"$l\"\n";
-	}
-	if ($self->{def})
-	{
-		my $d = $self->{def};
-		$d =~ s/__CFGNAME__/$cfgname/g;
-		print $f "\t\tModuleDefinitionFile=\"$d\"\n";
-	}
-
-	print $f "\t/>\n";
-	print $f
-	  "\t<Tool Name=\"VCLibrarianTool\" OutputFile=\".\\$cfgname\\$self->{name}\\$self->{name}.lib\" IgnoreDefaultLibraryNames=\"libc\" />\n";
-	print $f
-	  "\t<Tool Name=\"VCResourceCompilerTool\" AdditionalIncludeDirectories=\"src\\include\" />\n";
-	if ($self->{builddef})
-	{
-		print $f
-		  "\t<Tool Name=\"VCPreLinkEventTool\" Description=\"Generate DEF file\" CommandLine=\"perl src\\tools\\msvc\\gendef.pl $cfgname\\$self->{name} $self->{platform}\" />\n";
-	}
-	print $f <<EOF;
-  </Configuration>
-EOF
-	return;
-}
-
-sub WriteReferences
-{
-	my ($self, $f) = @_;
-	print $f " <References>\n";
-	foreach my $ref (@{ $self->{references} })
-	{
-		print $f
-		  "  <ProjectReference ReferencedProjectIdentifier=\"$ref->{guid}\" Name=\"$ref->{name}\" />\n";
-	}
-	print $f " </References>\n";
-	return;
-}
-
-sub GenerateCustomTool
-{
-	my ($self, $desc, $tool, $output, $cfg) = @_;
-	if (!defined($cfg))
-	{
-		return $self->GenerateCustomTool($desc, $tool, $output, 'Debug')
-		  . $self->GenerateCustomTool($desc, $tool, $output, 'Release');
-	}
-	return
-	  "<FileConfiguration Name=\"$cfg|$self->{platform}\"><Tool Name=\"VCCustomBuildTool\" Description=\"$desc\" CommandLine=\"$tool\" AdditionalDependencies=\"\" Outputs=\"$output\" /></FileConfiguration>";
-}
-
-package VC2005Project;
-
-#
-# Package that encapsulates a Visual C++ 2005 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver} = '8.00';
-
-	return $self;
-}
-
-package VC2008Project;
-
-#
-# Package that encapsulates a Visual C++ 2008 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver} = '9.00';
-
-	return $self;
-}
-
-1;
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 92a4fb6841f..1a94cd866ee 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -13,7 +13,6 @@ use warnings;
 use Exporter;
 use Project;
 use Solution;
-use VCBuildProject;
 use MSBuildProject;
 
 our (@ISA, @EXPORT);
@@ -31,23 +30,7 @@ sub CreateSolution
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '8.00')
-	{
-		return new VS2005Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '9.00')
-	{
-		return new VS2008Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '10.00')
-	{
-		return new VS2010Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '11.00')
-	{
-		return new VS2012Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '12.00')
+	if ($visualStudioVersion eq '12.00')
 	{
 		return new VS2013Solution(@_);
 	}
@@ -78,23 +61,7 @@ sub CreateProject
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '8.00')
-	{
-		return new VC2005Project(@_);
-	}
-	elsif ($visualStudioVersion eq '9.00')
-	{
-		return new VC2008Project(@_);
-	}
-	elsif ($visualStudioVersion eq '10.00')
-	{
-		return new VC2010Project(@_);
-	}
-	elsif ($visualStudioVersion eq '11.00')
-	{
-		return new VC2012Project(@_);
-	}
-	elsif ($visualStudioVersion eq '12.00')
+	if ($visualStudioVersion eq '12.00')
 	{
 		return new VC2013Project(@_);
 	}
diff --git a/src/tools/msvc/build.pl b/src/tools/msvc/build.pl
index 9a234d1cc25..35649fe5a24 100644
--- a/src/tools/msvc/build.pl
+++ b/src/tools/msvc/build.pl
@@ -53,16 +53,12 @@ elsif (uc($ARGV[0]) ne "RELEASE")
 
 # ... and do it
 
-if ($buildwhat and $vcver >= 10.00)
+if ($buildwhat)
 {
 	system(
 		"msbuild $buildwhat.vcxproj /verbosity:normal $msbflags /p:Configuration=$bconf"
 	);
 }
-elsif ($buildwhat)
-{
-	system("vcbuild $msbflags $buildwhat.vcproj $bconf");
-}
 else
 {
 	system(
-- 
2.18.0.rc2.dirty

v2-0002-Introduce-minimal-C99-usage-to-verify-compiler-su.patchtext/x-diff; charset=us-asciiDownload
From 15832a329d9f9bbeb6c31d916fd0b3d6f412c0f2 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:44:33 -0700
Subject: [PATCH v2 2/4] Introduce minimal C99 usage to verify compiler
 support.

This just converts a few for loops in postgres.c to declare variables
in the loop initializer, and uses designated initializers in smgr.c's
definition of smgr callbacks.

Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
 src/backend/storage/smgr/smgr.c | 21 ++++++++++++++++++---
 src/backend/tcop/postgres.c     | 25 +++++++------------------
 2 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/src/backend/storage/smgr/smgr.c b/src/backend/storage/smgr/smgr.c
index 08f06bade25..189342ef86a 100644
--- a/src/backend/storage/smgr/smgr.c
+++ b/src/backend/storage/smgr/smgr.c
@@ -67,9 +67,24 @@ typedef struct f_smgr
 
 static const f_smgr smgrsw[] = {
 	/* magnetic disk */
-	{mdinit, NULL, mdclose, mdcreate, mdexists, mdunlink, mdextend,
-		mdprefetch, mdread, mdwrite, mdwriteback, mdnblocks, mdtruncate,
-		mdimmedsync, mdpreckpt, mdsync, mdpostckpt
+	{
+		.smgr_init = mdinit,
+		.smgr_shutdown = NULL,
+		.smgr_close = mdclose,
+		.smgr_create = mdcreate,
+		.smgr_exists = mdexists,
+		.smgr_unlink = mdunlink,
+		.smgr_extend = mdextend,
+		.smgr_prefetch = mdprefetch,
+		.smgr_read = mdread,
+		.smgr_write = mdwrite,
+		.smgr_writeback = mdwriteback,
+		.smgr_nblocks = mdnblocks,
+		.smgr_truncate = mdtruncate,
+		.smgr_immedsync = mdimmedsync,
+		.smgr_pre_ckpt = mdpreckpt,
+		.smgr_sync = mdsync,
+		.smgr_post_ckpt = mdpostckpt
 	}
 };
 
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 07b956553a7..7a9ada2c719 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -1310,7 +1310,6 @@ exec_parse_message(const char *query_string,	/* string to execute */
 	{
 		Query	   *query;
 		bool		snapshot_set = false;
-		int			i;
 
 		raw_parse_tree = linitial_node(RawStmt, parsetree_list);
 
@@ -1366,7 +1365,7 @@ exec_parse_message(const char *query_string,	/* string to execute */
 		/*
 		 * Check all parameter types got determined.
 		 */
-		for (i = 0; i < numParams; i++)
+		for (int i = 0; i < numParams; i++)
 		{
 			Oid			ptype = paramTypes[i];
 
@@ -1555,10 +1554,8 @@ exec_bind_message(StringInfo input_message)
 	numPFormats = pq_getmsgint(input_message, 2);
 	if (numPFormats > 0)
 	{
-		int			i;
-
 		pformats = (int16 *) palloc(numPFormats * sizeof(int16));
-		for (i = 0; i < numPFormats; i++)
+		for (int i = 0; i < numPFormats; i++)
 			pformats[i] = pq_getmsgint(input_message, 2);
 	}
 
@@ -1641,8 +1638,6 @@ exec_bind_message(StringInfo input_message)
 	 */
 	if (numParams > 0)
 	{
-		int			paramno;
-
 		params = (ParamListInfo) palloc(offsetof(ParamListInfoData, params) +
 										numParams * sizeof(ParamExternData));
 		/* we have static list of params, so no hooks needed */
@@ -1654,7 +1649,7 @@ exec_bind_message(StringInfo input_message)
 		params->parserSetupArg = NULL;
 		params->numParams = numParams;
 
-		for (paramno = 0; paramno < numParams; paramno++)
+		for (int paramno = 0; paramno < numParams; paramno++)
 		{
 			Oid			ptype = psrc->param_types[paramno];
 			int32		plength;
@@ -1782,10 +1777,8 @@ exec_bind_message(StringInfo input_message)
 	numRFormats = pq_getmsgint(input_message, 2);
 	if (numRFormats > 0)
 	{
-		int			i;
-
 		rformats = (int16 *) palloc(numRFormats * sizeof(int16));
-		for (i = 0; i < numRFormats; i++)
+		for (int i = 0; i < numRFormats; i++)
 			rformats[i] = pq_getmsgint(input_message, 2);
 	}
 
@@ -2212,7 +2205,6 @@ errdetail_params(ParamListInfo params)
 	{
 		StringInfoData param_str;
 		MemoryContext oldcontext;
-		int			paramno;
 
 		/* This code doesn't support dynamic param lists */
 		Assert(params->paramFetch == NULL);
@@ -2222,7 +2214,7 @@ errdetail_params(ParamListInfo params)
 
 		initStringInfo(&param_str);
 
-		for (paramno = 0; paramno < params->numParams; paramno++)
+		for (int paramno = 0; paramno < params->numParams; paramno++)
 		{
 			ParamExternData *prm = &params->params[paramno];
 			Oid			typoutput;
@@ -2325,7 +2317,6 @@ static void
 exec_describe_statement_message(const char *stmt_name)
 {
 	CachedPlanSource *psrc;
-	int			i;
 
 	/*
 	 * Start up a transaction command. (Note that this will normally change
@@ -2384,7 +2375,7 @@ exec_describe_statement_message(const char *stmt_name)
 														 * message type */
 	pq_sendint16(&row_description_buf, psrc->num_params);
 
-	for (i = 0; i < psrc->num_params; i++)
+	for (int i = 0; i < psrc->num_params; i++)
 	{
 		Oid			ptype = psrc->param_types[i];
 
@@ -4179,10 +4170,8 @@ PostgresMain(int argc, char *argv[],
 					numParams = pq_getmsgint(&input_message, 2);
 					if (numParams > 0)
 					{
-						int			i;
-
 						paramTypes = (Oid *) palloc(numParams * sizeof(Oid));
-						for (i = 0; i < numParams; i++)
+						for (int i = 0; i < numParams; i++)
 							paramTypes[i] = pq_getmsgint(&input_message, 4);
 					}
 					pq_getmsgend(&input_message);
-- 
2.18.0.rc2.dirty

v2-0003-Remove-test-for-VA_ARGS-implied-by-C99.patchtext/x-diff; charset=us-asciiDownload
From 6f8acfd2c5ae1c296c8cc314ceb144beb6b353a7 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:04:47 -0700
Subject: [PATCH v2 3/4] Remove test for VA_ARGS, implied by C99.

This simplifies logic / reduces duplication in a few headers.

Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
 config/c-compiler.m4          | 19 -------------------
 configure                     | 32 --------------------------------
 configure.in                  |  1 -
 src/include/pg_config.h.in    |  3 ---
 src/include/pg_config.h.win32 |  3 ---
 src/include/utils/elog.h      |  8 +-------
 src/pl/plpython/plpy_elog.h   |  4 ----
 7 files changed, 1 insertion(+), 69 deletions(-)

diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 67675a31bb6..eedaf12d69c 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -415,25 +415,6 @@ fi])# PGAC_C_COMPUTED_GOTO
 
 
 
-# PGAC_C_VA_ARGS
-# --------------
-# Check if the C compiler understands C99-style variadic macros,
-# and define HAVE__VA_ARGS if so.
-AC_DEFUN([PGAC_C_VA_ARGS],
-[AC_CACHE_CHECK(for __VA_ARGS__, pgac_cv__va_args,
-[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <stdio.h>],
-[#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-])],
-[pgac_cv__va_args=yes],
-[pgac_cv__va_args=no])])
-if test x"$pgac_cv__va_args" = xyes ; then
-AC_DEFINE(HAVE__VA_ARGS, 1,
-          [Define to 1 if your compiler understands __VA_ARGS__ in macros.])
-fi])# PGAC_C_VA_ARGS
-
-
-
 # PGAC_PROG_VARCC_VARFLAGS_OPT
 # -----------------------
 # Given a compiler, variable name and a string, check if the compiler
diff --git a/configure b/configure
index dd439ddd2f6..b143c6d6ba4 100755
--- a/configure
+++ b/configure
@@ -13962,38 +13962,6 @@ if test x"$pgac_cv_computed_goto" = xyes ; then
 
 $as_echo "#define HAVE_COMPUTED_GOTO 1" >>confdefs.h
 
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __VA_ARGS__" >&5
-$as_echo_n "checking for __VA_ARGS__... " >&6; }
-if ${pgac_cv__va_args+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-#include <stdio.h>
-int
-main ()
-{
-#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  pgac_cv__va_args=yes
-else
-  pgac_cv__va_args=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__va_args" >&5
-$as_echo "$pgac_cv__va_args" >&6; }
-if test x"$pgac_cv__va_args" = xyes ; then
-
-$as_echo "#define HAVE__VA_ARGS 1" >>confdefs.h
-
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether struct tm is in sys/time.h or time.h" >&5
 $as_echo_n "checking whether struct tm is in sys/time.h or time.h... " >&6; }
diff --git a/configure.in b/configure.in
index 5869ab7c5bc..3280afa0dab 100644
--- a/configure.in
+++ b/configure.in
@@ -1434,7 +1434,6 @@ PGAC_C_BUILTIN_BSWAP64
 PGAC_C_BUILTIN_CONSTANT_P
 PGAC_C_BUILTIN_UNREACHABLE
 PGAC_C_COMPUTED_GOTO
-PGAC_C_VA_ARGS
 PGAC_STRUCT_TIMEZONE
 PGAC_UNION_SEMUN
 PGAC_STRUCT_SOCKADDR_UN
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index 827574ee40d..37649d77d67 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -754,9 +754,6 @@
 /* Define to 1 if your compiler understands _Static_assert. */
 #undef HAVE__STATIC_ASSERT
 
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#undef HAVE__VA_ARGS
-
 /* Define to 1 if you have the `__strtoll' function. */
 #undef HAVE___STRTOLL
 
diff --git a/src/include/pg_config.h.win32 b/src/include/pg_config.h.win32
index 46ce49def2f..4e2bd3c1352 100644
--- a/src/include/pg_config.h.win32
+++ b/src/include/pg_config.h.win32
@@ -597,9 +597,6 @@
 /* Define to 1 if your compiler understands _Static_assert. */
 /* #undef HAVE__STATIC_ASSERT */
 
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#define HAVE__VA_ARGS 1
-
 /* Define to the appropriate printf length modifier for 64-bit ints. */
 #define INT64_MODIFIER "ll"
 
diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h
index 4350b120aab..33c6b53e278 100644
--- a/src/include/utils/elog.h
+++ b/src/include/utils/elog.h
@@ -207,9 +207,8 @@ extern int	getinternalerrposition(void);
  *		elog(ERROR, "portal \"%s\" not found", stmt->portalname);
  *----------
  */
-#ifdef HAVE__VA_ARGS
 /*
- * If we have variadic macros, we can give the compiler a hint about the
+ * Using variadic macros, we can give the compiler a hint about the
  * call not returning when elevel >= ERROR.  See comments for ereport().
  * Note that historically elog() has called elog_start (which saves errno)
  * before evaluating "elevel", so we preserve that behavior here.
@@ -236,11 +235,6 @@ extern int	getinternalerrposition(void);
 		} \
 	} while(0)
 #endif							/* HAVE__BUILTIN_CONSTANT_P */
-#else							/* !HAVE__VA_ARGS */
-#define elog  \
-	elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), \
-	elog_finish
-#endif							/* HAVE__VA_ARGS */
 
 extern void elog_start(const char *filename, int lineno, const char *funcname);
 extern void elog_finish(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
diff --git a/src/pl/plpython/plpy_elog.h b/src/pl/plpython/plpy_elog.h
index e4b30c3cca1..b56ac412476 100644
--- a/src/pl/plpython/plpy_elog.h
+++ b/src/pl/plpython/plpy_elog.h
@@ -15,7 +15,6 @@ extern PyObject *PLy_exc_spi_error;
  *
  * See comments at elog() about the compiler hinting.
  */
-#ifdef HAVE__VA_ARGS
 #ifdef HAVE__BUILTIN_CONSTANT_P
 #define PLy_elog(elevel, ...) \
 	do { \
@@ -32,9 +31,6 @@ extern PyObject *PLy_exc_spi_error;
 			pg_unreachable(); \
 	} while(0)
 #endif							/* HAVE__BUILTIN_CONSTANT_P */
-#else							/* !HAVE__VA_ARGS */
-#define PLy_elog PLy_elog_impl
-#endif							/* HAVE__VA_ARGS */
 
 extern void PLy_elog_impl(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
 
-- 
2.18.0.rc2.dirty

#79Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Andres Freund (#78)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 23/08/2018 03:31, Andres Freund wrote:

On 2018-08-22 17:09:05 -0700, Andres Freund wrote:

Attached is a version doing so.

Mildly updated version attached. This adds an explanatory commit
message, removes one stray docs C89 reference, and fixes a mis-squashing
of a patch.

Let's do it!

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#80Andres Freund
andres@anarazel.de
In reply to: Peter Eisentraut (#79)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 2018-08-23 22:02:26 +0200, Peter Eisentraut wrote:

On 23/08/2018 03:31, Andres Freund wrote:

On 2018-08-22 17:09:05 -0700, Andres Freund wrote:

Attached is a version doing so.

Mildly updated version attached. This adds an explanatory commit
message, removes one stray docs C89 reference, and fixes a mis-squashing
of a patch.

Let's do it!

Pushed the first two. I'll send the presumably affected buildfarm
owners an email, asking them whether they want to update.

Greetings,

Andres Freund

#81Thomas Munro
thomas.munro@enterprisedb.com
In reply to: Andres Freund (#80)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On Fri, Aug 24, 2018 at 1:44 PM, Andres Freund <andres@anarazel.de> wrote:

On 2018-08-23 22:02:26 +0200, Peter Eisentraut wrote:

On 23/08/2018 03:31, Andres Freund wrote:

On 2018-08-22 17:09:05 -0700, Andres Freund wrote:

Attached is a version doing so.

Mildly updated version attached. This adds an explanatory commit
message, removes one stray docs C89 reference, and fixes a mis-squashing
of a patch.

Let's do it!

Pushed the first two. I'll send the presumably affected buildfarm
owners an email, asking them whether they want to update.

Note that designated initialisers are not in C++ yet (though IIUC they
have been accepted in P0329R4[1]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4691.html for the draft that will become C++20
whatever it turns out to be).

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4691.html

--
Thomas Munro
http://www.enterprisedb.com

#82Thomas Munro
thomas.munro@enterprisedb.com
In reply to: Thomas Munro (#30)
Re: C99 compliance for src/port/snprintf.c

On Thu, Aug 16, 2018 at 12:24 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:

FWIW cfbot is using Visual Studio 2010 right now. Appveyor provides
2008, 2010, 2012, 2013 (AKA 12.0), 2015, 2017, and to test with a
different toolchain you can take the example patch from
https://wiki.postgresql.org/wiki/Continuous_Integration and add a line
like this to the end of the install section (worked for me; for 2015+
you probably also need to request a different image):

- 'call "C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat" x86_amd64'

I'll make that change to cfbot if we decree that it is the new
baseline for PostgreSQL on Windows.

Done.

--
Thomas Munro
http://www.enterprisedb.com

#83Andres Freund
andres@anarazel.de
In reply to: Andres Freund (#80)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-23 18:44:34 -0700, Andres Freund wrote:

Pushed the first two.

Seems to have worked like expected.

I'll send the presumably affected buildfarm owners an email, asking
them whether they want to update.

Did that.

Andrew, as expected my buildfarm animal mylodon, which uses compiler
flags to enforce C89 compliance, failed due to this commit:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=mylodon&amp;br=HEAD

I'd like to change it so it doesn't enforce C89 compliance across the
board, but instead enforces the relevant standard. For that I'd need to
change CFLAGS per-branch in the buildfarm. Is that possible already? Do
I need two different config files?

Greetings,

Andres Freund

#84Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#83)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Andres Freund <andres@anarazel.de> writes:

I'd like to change it so it doesn't enforce C89 compliance across the
board, but instead enforces the relevant standard. For that I'd need to
change CFLAGS per-branch in the buildfarm. Is that possible already? Do
I need two different config files?

I just did that on dromedary, with a stanza like this at the bottom:

if ($branch eq 'HEAD' or $branch ge 'REL_12')
{
$conf{config_env}->{CC} = 'ccache gcc -std=c99';
}
else
{
$conf{config_env}->{CC} = 'ccache gcc -ansi';
}

regards, tom lane

#85Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#84)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 2018-08-24 12:10:34 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

I'd like to change it so it doesn't enforce C89 compliance across the
board, but instead enforces the relevant standard. For that I'd need to
change CFLAGS per-branch in the buildfarm. Is that possible already? Do
I need two different config files?

I just did that on dromedary, with a stanza like this at the bottom:

if ($branch eq 'HEAD' or $branch ge 'REL_12')
{
$conf{config_env}->{CC} = 'ccache gcc -std=c99';
}
else
{
$conf{config_env}->{CC} = 'ccache gcc -ansi';
}

Thanks, did something similar, mylodon should become green soon. I kinda
was hoping that CFLAGS would directly accept version specific like some
other vars directly...

Greetings,

Andres Freund

#86Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Andres Freund (#83)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/24/2018 11:46 AM, Andres Freund wrote:

Hi,

On 2018-08-23 18:44:34 -0700, Andres Freund wrote:

Pushed the first two.

Seems to have worked like expected.

I'll send the presumably affected buildfarm owners an email, asking
them whether they want to update.

Did that.

I have installed VS2017 on bowerbird and a test is currently running.
It's got past the make phase so I assume everything is kosher.

However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5.
Perhaps we should consider backpatching support for those down to 9.3.

If not, I will just restrict bowerbird to building 9.6 and up. That's
fine by me, we'll still have coverage from, say, currawong, but it's a
pity we'll only be able to support the older compilers on the old branches.

Andrew, as expected my buildfarm animal mylodon, which uses compiler
flags to enforce C89 compliance, failed due to this commit:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=mylodon&amp;br=HEAD

I'd like to change it so it doesn't enforce C89 compliance across the
board, but instead enforces the relevant standard. For that I'd need to
change CFLAGS per-branch in the buildfarm. Is that possible already? Do
I need two different config files?

I saw Tom's answer, and it will work as far as it goes. But maybe we
should look at doing that in configure instead of putting the onus on
all buildfarm owners? It already knows if it's using a GNU compiler, not
sure how ubiquitous the -ansi and -std=c99 flags are.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#87Andres Freund
andres@anarazel.de
In reply to: Andrew Dunstan (#86)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:

I have installed VS2017 on bowerbird and a test is currently running. It's
got past the make phase so I assume everything is kosher.

Cool, thanks.

However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
we should consider backpatching support for those down to 9.3.

Hm, I have no strong objections to that. I don't think it's strictly
necessary, given 2013 is supported across the board, but for the non MSVC
world, we do fix compiler issues in older branches. There's not that
much code for the newer versions afaict?

Greetings,

Andres Freund

#88Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#86)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

I saw Tom's answer, and it will work as far as it goes. But maybe we
should look at doing that in configure instead of putting the onus on
all buildfarm owners? It already knows if it's using a GNU compiler, not
sure how ubiquitous the -ansi and -std=c99 flags are.

No, the only reason either of us are doing that is to force use of a
flag that's different from what configure would select by default
(which evidently is -std=gnu99 for gcc). Most buildfarm owners have
no need to do anything.

regards, tom lane

#89Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#87)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Andres Freund <andres@anarazel.de> writes:

On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:

However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
we should consider backpatching support for those down to 9.3.

Hm, I have no strong objections to that. I don't think it's strictly
necessary, given 2013 is supported across the board, but for the non MSVC
world, we do fix compiler issues in older branches. There's not that
much code for the newer versions afaict?

+1 for taking a look at how big a patch it would be. But I kind of
thought we'd intentionally rejected back-patching some of those changes
to begin with, so I'm not sure the end decision will change.

regards, tom lane

#90Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Tom Lane (#88)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/24/2018 02:36 PM, Tom Lane wrote:

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

I saw Tom's answer, and it will work as far as it goes. But maybe we
should look at doing that in configure instead of putting the onus on
all buildfarm owners? It already knows if it's using a GNU compiler, not
sure how ubiquitous the -ansi and -std=c99 flags are.

No, the only reason either of us are doing that is to force use of a
flag that's different from what configure would select by default
(which evidently is -std=gnu99 for gcc). Most buildfarm owners have
no need to do anything.

Ah. Ok. Then your answer is good.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#91Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Tom Lane (#89)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/24/2018 02:38 PM, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:

However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
we should consider backpatching support for those down to 9.3.

Hm, I have no strong objections to that. I don't think it's strictly
necessary, given 2013 is supported across the board, but for the non MSVC
world, we do fix compiler issues in older branches. There's not that
much code for the newer versions afaict?

+1 for taking a look at how big a patch it would be. But I kind of
thought we'd intentionally rejected back-patching some of those changes
to begin with, so I'm not sure the end decision will change.

The VS2017 patch applies cleanly to 9.5, so that seems easy. The VS2015
patch from 9.5 needs a very small amount of adjustment by the look of it
for 9.3 and 9.4, after which I hope the VS2017 patch would again apply
cleanly.

I'll try to put this together.

The trouble with not back patching support to all live branches as new
versions come in is that it acts as a significant discouragement to
buildfarm owners to use the latest Visual Studio versions. I've never
argued stringly on this point before, but I think i'm goiung to ber
inclined to in future.

Meanwhile, I will turn bowerbird back on but just for >= 9.6 for now.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#92Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#47)
Re: C99 compliance for src/port/snprintf.c

Andres Freund <andres@anarazel.de> writes:

On 2018-08-16 11:41:30 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
still confused what causes this error mode. Kinda looks like
out-of-sync headers with gcc or something.

Yeah, this is *absolutely* unsurprising for a non-native gcc installation
on an old platform.

Sure, but that still requires the headers to behave differently between
C89 and C99 mode, as this worked before. But it turns out there's two
different math.h implementation headers, depending on c99 being enabled
(math_c99.h being the troublesome). If I understand correctly the
problem is more that the system library headers are *newer* (and assume
a sun studio emulating/copying quite a bit of gcc) than the gcc that's
being used, and therefore gcc fails.

I have some more info on this issue, based on having successfully
updated "gaur" using gcc 3.4.6 (which I picked because it was the last
of the 3.x release series). It seems very unlikely that there's much
difference between 3.4.3 and 3.4.6 as far as external features go.
What I find in the 3.4.6 documentation is

-- Built-in Function: double __builtin_inf (void)
Similar to `__builtin_huge_val', except a warning is generated if
the target floating-point format does not support infinities.
This function is suitable for implementing the ISO C99 macro
`INFINITY'.

Note that the function is called "__builtin_inf", whereas what we see
protosciurus choking on is "__builtin_infinity". So I don't think this
is a version skew issue at all. I think that the system headers are
written for the Solaris cc, and its name for the equivalent function is
__builtin_infinity, whereas what gcc wants is __builtin_inf. Likewise,
the failures we see for __builtin_isinf and __builtin_isnan are because
Solaris cc provides those but gcc does not.

If we wanted to keep protosciurus going without a compiler update, my
thought would be to modify gcc's copy of math_c99.h to correct the
function name underlying INFINITY, and change the definitions of isinf()
and isnan() back to whatever was being used pre-C99.

It's possible that newer gcc releases have been tweaked so that they
make appropriate corrections in this header file automatically, but
that's not a sure thing.

regards, tom lane

#93Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Andrew Dunstan (#91)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

On 08/24/2018 03:42 PM, Andrew Dunstan wrote:

On 08/24/2018 02:38 PM, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:

However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5.
Perhaps
we should consider backpatching support for those down to 9.3.

Hm, I have no strong objections to that.   I don't think it's strictly
necessary, given 2013 is supported across the board, but for the non
MSVC
world, we do fix compiler issues in older branches.  There's not that
much code for the newer versions afaict?

+1 for taking a look at how big a patch it would be.  But I kind of
thought we'd intentionally rejected back-patching some of those changes
to begin with, so I'm not sure the end decision will change.

The VS2017 patch applies cleanly to 9.5, so that seems easy. The
VS2015 patch from 9.5 needs a very small amount of adjustment by the
look of it for 9.3 and 9.4, after which I hope the VS2017 patch would
again apply cleanly.

I'll try to put this together.

The trouble with not back patching support to all live branches as new
versions come in is that it acts as a significant discouragement to
buildfarm owners to use the latest Visual Studio versions. I've never
argued stringly on this point before, but I think i'm goiung to ber
inclined to in future.

Meanwhile, I will turn bowerbird back on but just for >= 9.6 for now.

I've pushed support for the latest MSVC compilers back to all live branches.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#94Andres Freund
andres@anarazel.de
In reply to: Andrew Dunstan (#93)
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

Hi,

On 2018-09-11 16:13:15 -0400, Andrew Dunstan wrote:

I've pushed support for the latest MSVC compilers back to all live branches.

Thanks!

Greetings,

Andres Freund

#95Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#92)
Re: C99 compliance for src/port/snprintf.c

Hi,

On 2018-08-25 13:08:18 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2018-08-16 11:41:30 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
still confused what causes this error mode. Kinda looks like
out-of-sync headers with gcc or something.

Yeah, this is *absolutely* unsurprising for a non-native gcc installation
on an old platform.

Sure, but that still requires the headers to behave differently between
C89 and C99 mode, as this worked before. But it turns out there's two
different math.h implementation headers, depending on c99 being enabled
(math_c99.h being the troublesome). If I understand correctly the
problem is more that the system library headers are *newer* (and assume
a sun studio emulating/copying quite a bit of gcc) than the gcc that's
being used, and therefore gcc fails.

I have some more info on this issue, based on having successfully
updated "gaur" using gcc 3.4.6 (which I picked because it was the last
of the 3.x release series). It seems very unlikely that there's much
difference between 3.4.3 and 3.4.6 as far as external features go.
What I find in the 3.4.6 documentation is

-- Built-in Function: double __builtin_inf (void)
Similar to `__builtin_huge_val', except a warning is generated if
the target floating-point format does not support infinities.
This function is suitable for implementing the ISO C99 macro
`INFINITY'.

Note that the function is called "__builtin_inf", whereas what we see
protosciurus choking on is "__builtin_infinity". So I don't think this
is a version skew issue at all. I think that the system headers are
written for the Solaris cc, and its name for the equivalent function is
__builtin_infinity, whereas what gcc wants is __builtin_inf. Likewise,
the failures we see for __builtin_isinf and __builtin_isnan are because
Solaris cc provides those but gcc does not.

If we wanted to keep protosciurus going without a compiler update, my
thought would be to modify gcc's copy of math_c99.h to correct the
function name underlying INFINITY, and change the definitions of isinf()
and isnan() back to whatever was being used pre-C99.

It's possible that newer gcc releases have been tweaked so that they
make appropriate corrections in this header file automatically, but
that's not a sure thing.

I've pinged Dave about this, and he said:

On 2018-09-26 17:04:29 -0400, Dave Page wrote:

Unfortunately, i think that whole machine is basically EOL now. It's
already skipping OpenSSL for some builds, as being stuck on a very old
version of the buildfarm client, as some of the modules used in newer
versions just won't compile or work. I don't have any support contract, or
access to newer versions of SunStudio, and the guys that used to package
GCC for Solaris now charge to download their packages.

I could potentially build my own version of GCC, but I question whether
it's really worth it, given the other problems.

He's now disabled building master on protosciurus and casteroides. We
still have damselfly and rover_firefly so I don't feel too bad about
that. I've pinged their owners to ask whether they could set up a sun
studio (or however that's called in their solaris descendants) version.

Greetings,

Andres Freund