| From: | Rui Zhao <zhaorui126(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fix more casting away of qualifiers |
| Date: | 2026-10-01 16:44:13 |
| Message-ID: | CAHWVJhGWO0bahAYhE-Cg5+5F9JdHEXA_75_DcyzAY_fkF8Ykng@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Peter,
I like this cleanup, especially removing the need to cast const char *
to char * just to call a function that only reads the input.
> The first two patches address the issue that unconstify cannot be used
> for global variables.
With GCC 10.2 and Clang 15, I checked that unconstify_constexpr works
in static initializers and that both unconstify_constexpr and
unconstify still reject casts to an incompatible pointer type.
V2 0001-0007 compiled with both compilers. I enabled OpenSSL and
GSSAPI in both builds to cover their API casts in 0004.
I also ran the same tests with both builds to check for behavior
changes: core regression, postgres_fdw, psql and PL/Python. All passed.
One small thing in 0005, in src/backend/utils/adt/float.c: the comment
above float8in_internal() still says:
> "num" could validly be declared "const char *", but that results in an
> unreasonable amount of extra casting both here and in callers,
> so we don't.
Could we remove those two lines now that num is const char *?
Otherwise, 0001-0007 look good to me.
Regards,
Rui
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikolay Samokhvalov | 2026-10-01 16:47:33 | Re: postgres_fdw: transaction mode inheritance corner cases |
| Previous Message | Soumen | 2026-10-01 16:31:27 | Request to expedite cool-off |