aboutsummaryrefslogtreecommitdiff
path: root/src/backend/replication/logical/reorderbuffer.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-08-15 17:25:23 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-08-15 17:25:49 -0400
commit36147ec9f1e2dcbe35fc813825242d72d1c57b70 (patch)
tree671f4d0a48122ab875b314631d32a9ded4a28c58 /src/backend/replication/logical/reorderbuffer.c
parent6872c2be6a97057aa736110e31f0390a53305c9e (diff)
downloadpostgresql-36147ec9f1e2dcbe35fc813825242d72d1c57b70.tar.gz
postgresql-36147ec9f1e2dcbe35fc813825242d72d1c57b70.zip
Make snprintf.c follow the C99 standard for snprintf's result value.
C99 says that the result should be the number of bytes that would have been emitted given a large enough buffer, not the number we actually were able to put in the buffer. It's time to make our substitute implementation comply with that. Not doing so results in inefficiency in buffer-enlargement cases, and also poses a portability hazard for third-party code that might expect C99-compliant snprintf behavior within Postgres. In passing, remove useless tests for str == NULL; neither C99 nor predecessor standards ever allowed that except when count == 0, so I see no reason to expend cycles on making that a non-crash case for this implementation. Also, don't waste a byte in pg_vfprintf's local I/O buffer; this might have performance benefits by allowing aligned writes during flushbuffer calls. Back-patch of commit 805889d7d. There was some concern about this possibly breaking code that assumes pre-C99 behavior, but there is much more risk (and reality, in our own code) of code that assumes C99 behavior and hence fails to detect buffer overrun without this. Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us
Diffstat (limited to 'src/backend/replication/logical/reorderbuffer.c')
0 files changed, 0 insertions, 0 deletions