Re: [PATCH v1] Replace sprintf() with snprintf() in libpq for safety Anexo: o arquivo

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Thiago Caserta <caserta(at)movestax(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v1] Replace sprintf() with snprintf() in libpq for safety Anexo: o arquivo
Date: 2026-03-26 23:33:27
Message-ID: 202603262322.jvxx26ed3eu5@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Mar-24, Thiago Caserta wrote:

> Hi hackers,
>
> Attached is a patch that converts several sprintf() calls to
> snprintf() in libpq client library code. While the existing buffers
> are currently sized correctly, using snprintf() provides an
> additional safety net against potential buffer overflows and is
> consistent with the project's general direction of preferring bounded
> string operations.

I'm not sure we should take a patch with a tag attributing authorship to
an LLM owned by a commercial entity. I think some US court already
ruled that LLMs aren't entitled to copyright for works of art, so I
suspect we don't need to make any such attribution.

On the other hand, the proposed patch is quite dumb, since at least the
first hunk shows duplicated strlen(). So it's not clear to me that this
patch really achieves the claimed "additional safety net".

Do we really want to be accepting code patches written by tools that
make the most obvious code worse than before? I am quite scared of the
quality of code of medium complexity written by this tool.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Los trabajadores menos efectivos son sistematicamente llevados al lugar
donde pueden hacer el menor daño posible: gerencia." (El principio Dilbert)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-03-26 23:51:14 Re: Initial COPY of Logical Replication is too slow
Previous Message Michael Paquier 2026-03-26 23:32:52 Re: dshash_find_or_insert vs. OOM