Re: Using the %m printf format more
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Cc: pgsql-hackers@postgresql.org
Date: 2024-03-11T06:30:30Z
Lists: pgsql-hackers
On Wed, Mar 06, 2024 at 07:11:19PM +0000, Dagfinn Ilmari Mannsåker wrote: > I just noticed that commit d93627bc added a bunch of pg_fatal() calls > using %s and strerror(errno), which could be written more concisely as > %m. I'm assuming this was done because the surrounding code also uses > this pattern, and hadn't been changed to use %m when support for that > was added to snprintf.c to avoid backporting hazards. However, that > support was in v12, which is now the oldest still-supported back branch, > so we can safely make that change. Right. This may still create some spurious conflicts, but that's manageable for error strings. The changes in your patch look OK. > The attached patch does so everywhere appropriate. One place where it's > not appropriate is the TAP-emitting functions in pg_regress, since those > call fprintf() I am not really following your argument with pg_regress.c and fprintf(). d6c55de1f99a should make that possible even in the case of emit_tap_output_v(), no? > and other potentially errno-modifying functions before > evaluating the format string. Sure. -- Michael
Commits
-
pg_regress: Save errno in emit_tap_output_v() and switch to %m
- 85230a247c74 17.0 landed
-
Use printf's %m format instead of strerror(errno) in more places
- 2c8118ee5d98 17.0 landed
-
Add --copy-file-range option to pg_upgrade.
- d93627bcbe50 17.0 cited