Outdated comment on scram_build_secret
Hi,
The documentation for the iterations parameter on scram_build_secret say:
* If iterations is 0, default number of iterations is used.
But the body of the function have the following assert
Assert(iterations > 0);
Commit b577743000 introduced the assert and remove the if condition.
All usages of this function is using an iteration > 0, so I think that
is just a matter of updating the documentation? If that's the case the
attached patch does that.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
Attachments:
v1-0001-Fix-outdated-scram_build_secret-comment.patchtext/plain; charset=UTF-8; name=v1-0001-Fix-outdated-scram_build_secret-comment.patchDownload
From c560e0c5b7e51e48314c6e3ada6126f9ef27d8e3 Mon Sep 17 00:00:00 2001
From: Matheus Alcantara <mths.dev@pm.me>
Date: Mon, 9 Dec 2024 20:36:30 -0300
Subject: [PATCH v1] Fix outdated scram_build_secret comment
---
src/common/scram-common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/common/scram-common.c b/src/common/scram-common.c
index b611bb8fe7..51cc12e8c3 100644
--- a/src/common/scram-common.c
+++ b/src/common/scram-common.c
@@ -200,8 +200,7 @@ scram_ServerKey(const uint8 *salted_password,
*
* The password should already have been processed with SASLprep, if necessary!
*
- * If iterations is 0, default number of iterations is used. The result is
- * palloc'd or malloc'd, so caller is responsible for freeing it.
+ * The result is palloc'd or malloc'd, so caller is responsible for freeing it.
*
* On error, returns NULL and sets *errstr to point to a message about the
* error details.
--
2.39.3 (Apple Git-146)
On Mon, Dec 09, 2024 at 08:39:03PM -0300, Matheus Alcantara wrote:
Commit b577743000 introduced the assert and remove the if condition. All
usages of this function is using an iteration > 0, so I think that is just a
matter of updating the documentation? If that's the case the attached patch
does that.
Ah, good catch.
- * If iterations is 0, default number of iterations is used. The result is - * palloc'd or malloc'd, so caller is responsible for freeing it. + * The result is palloc'd or malloc'd, so caller is responsible for freeing it.
Removing the comment sounds like the right thing to do here. I'll go
do that in a bit down to v16.
--
Michael