agora inbox for pgsql-committers@postgresql.org  
help / color / mirror / Atom feed
pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
7+ messages / 1 participants
[nested] [flat]

* pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
@ 2026-09-25 19:34  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-09-25 19:34 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Modernize crypt-des.c a bit, avoiding dubious casts.

The header comment for this file says it assumes that "the CPU is not
picky about alignment", which we wouldn't really accept for Postgres.
The two functions that have alignment requirements have been hacked in
ways that are inconsistent and yet both ugly.  des_setkey just casts
its "const char *" argument to "const uint32 *", relying on the caller
to ensure that that pointer is actually word-aligned, which the caller
does by declaring the buffer as uint32[] and then casting to "char *".
Meanwhile des_cipher carefully memcpy's to and from an internal
uint32[] buffer, which is pretty silly given that what it's passed
must be word-aligned for the benefit of des_setkey.  And on top of
that we have a bunch of ugly casting and oddly-written pointer
arithmetic in the caller px_crypt_des.  The odd pointer arithmetic
causes warnings about possible buffer overrun when using recent gcc
at -O3 or higher.

Let's clean this up by converting the buffer variable into a union
of a uint8 array and a uint32 array, so that we can remove all these
casts, and also replace the strange loop logic with a simple subscript
variable to satisfy gcc.

Reported-by: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Discussion: https://postgr.es/m/2005885.1790359097@sss.pgh.pa.us
Discussion: https://postgr.es/m/3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo
Backpatch-through: 14

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/87762cbaa4fefa2911c156f73f585b3ba522bab0

Modified Files
--------------
contrib/pgcrypto/crypt-des.c | 53 ++++++++++++++++++--------------------------
1 file changed, 21 insertions(+), 32 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
@ 2026-09-25 19:34  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-09-25 19:34 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Modernize crypt-des.c a bit, avoiding dubious casts.

The header comment for this file says it assumes that "the CPU is not
picky about alignment", which we wouldn't really accept for Postgres.
The two functions that have alignment requirements have been hacked in
ways that are inconsistent and yet both ugly.  des_setkey just casts
its "const char *" argument to "const uint32 *", relying on the caller
to ensure that that pointer is actually word-aligned, which the caller
does by declaring the buffer as uint32[] and then casting to "char *".
Meanwhile des_cipher carefully memcpy's to and from an internal
uint32[] buffer, which is pretty silly given that what it's passed
must be word-aligned for the benefit of des_setkey.  And on top of
that we have a bunch of ugly casting and oddly-written pointer
arithmetic in the caller px_crypt_des.  The odd pointer arithmetic
causes warnings about possible buffer overrun when using recent gcc
at -O3 or higher.

Let's clean this up by converting the buffer variable into a union
of a uint8 array and a uint32 array, so that we can remove all these
casts, and also replace the strange loop logic with a simple subscript
variable to satisfy gcc.

Reported-by: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Discussion: https://postgr.es/m/2005885.1790359097@sss.pgh.pa.us
Discussion: https://postgr.es/m/3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo
Backpatch-through: 14

Branch
------
REL_19_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/407687a0fb1b48223337ad3018775c4a463ba29e

Modified Files
--------------
contrib/pgcrypto/crypt-des.c | 53 ++++++++++++++++++--------------------------
1 file changed, 21 insertions(+), 32 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
@ 2026-09-25 19:34  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-09-25 19:34 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Modernize crypt-des.c a bit, avoiding dubious casts.

The header comment for this file says it assumes that "the CPU is not
picky about alignment", which we wouldn't really accept for Postgres.
The two functions that have alignment requirements have been hacked in
ways that are inconsistent and yet both ugly.  des_setkey just casts
its "const char *" argument to "const uint32 *", relying on the caller
to ensure that that pointer is actually word-aligned, which the caller
does by declaring the buffer as uint32[] and then casting to "char *".
Meanwhile des_cipher carefully memcpy's to and from an internal
uint32[] buffer, which is pretty silly given that what it's passed
must be word-aligned for the benefit of des_setkey.  And on top of
that we have a bunch of ugly casting and oddly-written pointer
arithmetic in the caller px_crypt_des.  The odd pointer arithmetic
causes warnings about possible buffer overrun when using recent gcc
at -O3 or higher.

Let's clean this up by converting the buffer variable into a union
of a uint8 array and a uint32 array, so that we can remove all these
casts, and also replace the strange loop logic with a simple subscript
variable to satisfy gcc.

Reported-by: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Discussion: https://postgr.es/m/2005885.1790359097@sss.pgh.pa.us
Discussion: https://postgr.es/m/3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo
Backpatch-through: 14

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/e1b2a86d6e7e9a93039d3893b62c913d8b4164af

Modified Files
--------------
contrib/pgcrypto/crypt-des.c | 53 ++++++++++++++++++--------------------------
1 file changed, 21 insertions(+), 32 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
@ 2026-09-25 19:34  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-09-25 19:34 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Modernize crypt-des.c a bit, avoiding dubious casts.

The header comment for this file says it assumes that "the CPU is not
picky about alignment", which we wouldn't really accept for Postgres.
The two functions that have alignment requirements have been hacked in
ways that are inconsistent and yet both ugly.  des_setkey just casts
its "const char *" argument to "const uint32 *", relying on the caller
to ensure that that pointer is actually word-aligned, which the caller
does by declaring the buffer as uint32[] and then casting to "char *".
Meanwhile des_cipher carefully memcpy's to and from an internal
uint32[] buffer, which is pretty silly given that what it's passed
must be word-aligned for the benefit of des_setkey.  And on top of
that we have a bunch of ugly casting and oddly-written pointer
arithmetic in the caller px_crypt_des.  The odd pointer arithmetic
causes warnings about possible buffer overrun when using recent gcc
at -O3 or higher.

Let's clean this up by converting the buffer variable into a union
of a uint8 array and a uint32 array, so that we can remove all these
casts, and also replace the strange loop logic with a simple subscript
variable to satisfy gcc.

Reported-by: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Discussion: https://postgr.es/m/2005885.1790359097@sss.pgh.pa.us
Discussion: https://postgr.es/m/3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo
Backpatch-through: 14

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/5f664e6128235f7446ab02354ca9345a55f97255

Modified Files
--------------
contrib/pgcrypto/crypt-des.c | 53 ++++++++++++++++++--------------------------
1 file changed, 21 insertions(+), 32 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
@ 2026-09-25 19:34  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-09-25 19:34 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Modernize crypt-des.c a bit, avoiding dubious casts.

The header comment for this file says it assumes that "the CPU is not
picky about alignment", which we wouldn't really accept for Postgres.
The two functions that have alignment requirements have been hacked in
ways that are inconsistent and yet both ugly.  des_setkey just casts
its "const char *" argument to "const uint32 *", relying on the caller
to ensure that that pointer is actually word-aligned, which the caller
does by declaring the buffer as uint32[] and then casting to "char *".
Meanwhile des_cipher carefully memcpy's to and from an internal
uint32[] buffer, which is pretty silly given that what it's passed
must be word-aligned for the benefit of des_setkey.  And on top of
that we have a bunch of ugly casting and oddly-written pointer
arithmetic in the caller px_crypt_des.  The odd pointer arithmetic
causes warnings about possible buffer overrun when using recent gcc
at -O3 or higher.

Let's clean this up by converting the buffer variable into a union
of a uint8 array and a uint32 array, so that we can remove all these
casts, and also replace the strange loop logic with a simple subscript
variable to satisfy gcc.

Reported-by: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Discussion: https://postgr.es/m/2005885.1790359097@sss.pgh.pa.us
Discussion: https://postgr.es/m/3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo
Backpatch-through: 14

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/901952844bfcd936e961ed7f38ed7c9a8098be48

Modified Files
--------------
contrib/pgcrypto/crypt-des.c | 53 ++++++++++++++++++--------------------------
1 file changed, 21 insertions(+), 32 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
@ 2026-09-25 19:34  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-09-25 19:34 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Modernize crypt-des.c a bit, avoiding dubious casts.

The header comment for this file says it assumes that "the CPU is not
picky about alignment", which we wouldn't really accept for Postgres.
The two functions that have alignment requirements have been hacked in
ways that are inconsistent and yet both ugly.  des_setkey just casts
its "const char *" argument to "const uint32 *", relying on the caller
to ensure that that pointer is actually word-aligned, which the caller
does by declaring the buffer as uint32[] and then casting to "char *".
Meanwhile des_cipher carefully memcpy's to and from an internal
uint32[] buffer, which is pretty silly given that what it's passed
must be word-aligned for the benefit of des_setkey.  And on top of
that we have a bunch of ugly casting and oddly-written pointer
arithmetic in the caller px_crypt_des.  The odd pointer arithmetic
causes warnings about possible buffer overrun when using recent gcc
at -O3 or higher.

Let's clean this up by converting the buffer variable into a union
of a uint8 array and a uint32 array, so that we can remove all these
casts, and also replace the strange loop logic with a simple subscript
variable to satisfy gcc.

Reported-by: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Discussion: https://postgr.es/m/2005885.1790359097@sss.pgh.pa.us
Discussion: https://postgr.es/m/3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo
Backpatch-through: 14

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/35136da00e171b6990dd7363a6023ea9f2292e34

Modified Files
--------------
contrib/pgcrypto/crypt-des.c | 53 ++++++++++++++++++--------------------------
1 file changed, 21 insertions(+), 32 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Modernize crypt-des.c a bit, avoiding dubious casts.
@ 2026-09-25 19:34  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-09-25 19:34 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Modernize crypt-des.c a bit, avoiding dubious casts.

The header comment for this file says it assumes that "the CPU is not
picky about alignment", which we wouldn't really accept for Postgres.
The two functions that have alignment requirements have been hacked in
ways that are inconsistent and yet both ugly.  des_setkey just casts
its "const char *" argument to "const uint32 *", relying on the caller
to ensure that that pointer is actually word-aligned, which the caller
does by declaring the buffer as uint32[] and then casting to "char *".
Meanwhile des_cipher carefully memcpy's to and from an internal
uint32[] buffer, which is pretty silly given that what it's passed
must be word-aligned for the benefit of des_setkey.  And on top of
that we have a bunch of ugly casting and oddly-written pointer
arithmetic in the caller px_crypt_des.  The odd pointer arithmetic
causes warnings about possible buffer overrun when using recent gcc
at -O3 or higher.

Let's clean this up by converting the buffer variable into a union
of a uint8 array and a uint32 array, so that we can remove all these
casts, and also replace the strange loop logic with a simple subscript
variable to satisfy gcc.

Reported-by: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Discussion: https://postgr.es/m/2005885.1790359097@sss.pgh.pa.us
Discussion: https://postgr.es/m/3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo
Backpatch-through: 14

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/2a972dd5fb13489e057b0237bd5f7c8f6ef35b86

Modified Files
--------------
contrib/pgcrypto/crypt-des.c | 53 ++++++++++++++++++--------------------------
1 file changed, 21 insertions(+), 32 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread


end of thread, other threads:[~2026-09-25 19:34 UTC | newest]

Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-25 19:34 pgsql: Modernize crypt-des.c a bit, avoiding dubious casts. Tom Lane <tgl@sss.pgh.pa.us>
2026-09-25 19:34 pgsql: Modernize crypt-des.c a bit, avoiding dubious casts. Tom Lane <tgl@sss.pgh.pa.us>
2026-09-25 19:34 pgsql: Modernize crypt-des.c a bit, avoiding dubious casts. Tom Lane <tgl@sss.pgh.pa.us>
2026-09-25 19:34 pgsql: Modernize crypt-des.c a bit, avoiding dubious casts. Tom Lane <tgl@sss.pgh.pa.us>
2026-09-25 19:34 pgsql: Modernize crypt-des.c a bit, avoiding dubious casts. Tom Lane <tgl@sss.pgh.pa.us>
2026-09-25 19:34 pgsql: Modernize crypt-des.c a bit, avoiding dubious casts. Tom Lane <tgl@sss.pgh.pa.us>
2026-09-25 19:34 pgsql: Modernize crypt-des.c a bit, avoiding dubious casts. Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox