Feedback-ID: id4a34324:Fastmail
Date: Fri, 1 May 2026 12:40:54 -0400
From: Andres Freund <andres@anarazel.de>
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Refactor: allow pg_strncoll(), etc., to accept -1 length for
 NUL-terminated cstrings.
Message-ID: <s32n3tm2mjh247f3xkkxkdk7cf77hglbr3ia3hrsdjylajou7y@nlldpag3tjd5>
References: <2d758e07dff26bcc7cbe2aec57431329bfe3679a.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2d758e07dff26bcc7cbe2aec57431329bfe3679a.camel@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/s32n3tm2mjh247f3xkkxkdk7cf77hglbr3ia3hrsdjylajou7y%40nlldpag3tjd5>
Precedence: bulk

Hi,

On 2024-08-22 11:00:54 -0700, Jeff Davis wrote:
> Like ICU, allow -1 length to mean that the input string is NUL-
> terminated for pg_strncoll(), pg_strnxfrm(), and pg_strnxfrm_prefix().
> 
> This simplifies the API and code a bit.

I don't really like this.  I was hacking on a patch that uses compiler
annotations to tell the compiler what range of memory a function access. The
compiler then can use that knowledge to give you both compile-time warnings
and, more importantly, it makes ubsan much more accurate. It'll e.g. often be
able to warn you if a function accesses more memory than its annotation would
suggest, even if the memory is part of a larger memory allocation (something
asan, valgrind etc can't warn about, yet are often the most security critical
issues).  I found a bunch of issues that way already.

But the annotations can't work if the access size is sometimes is -1.

I also don't find this very convincing code-wise. You end up with lots of
branches for -1. You have to support cases where one of the arguments is
specifies as -1 and the other one with a real length, even though that's
presumably a non-existing case.

It seems reasonable to want the more efficient path for zero terminated
strings with libc, but it seems like if we want that, we should add add a
collate_method->strcoll, rather than have a strncoll that's not actually
strncoll but strcoll.

Greetings,

Andres Freund