From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | warnings for invalid function casts |
Date: | 2020-06-30 06:47:56 |
Message-ID: | 1e97628e-6447-b4fd-e230-d109cec2d584@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Some time ago, there were some discussions about gcc warnings produced
by -Wcast-function-type [0]. To clarify, while that thread seemed to
imply that the warnings appear by default in some compiler version, this
is not the case AFAICT, and the warnings are entirely optional.
So I took a look at what it would take to fix all the warnings and came
up with the attached patch.
There are three subplots:
1. Changing the return type of load_external_function() and
lookup_external_function() from PGFunction to a generic pointer type,
which is what the discussion in [0] started out about.
2. There is a bit of cheating in dynahash.c. They keycopy field is
declared as a function pointer that returns a pointer to the
destination, to match the signature of memcpy(), but then we assign
strlcpy() to it, which returns size_t. Even though we never use the
return value, I'm not sure whether this could break if size_t and
pointers are of different sizes, which in turn is very unlikely.
3. Finally, there is some nonsense necessary in plpython, which is
annoying but otherwise uninteresting.
Is there anything we want to pursue further here?
[0]:
https://www.postgresql.org/message-id/flat/20180206200205.f5kvbyn6jawtzi6s%40alap3.anarazel.de
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-Wcast-function-type-warnings.patch | text/plain | 10.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Biryukov | 2020-06-30 07:09:13 | Re: posgres 12 bug (partitioned table) |
Previous Message | Suraj Kharage | 2020-06-30 06:19:34 | Re: refactoring basebackup.c |