On 16/8/25 02:18, Chuck Lever via Libtirpc-devel wrote:
On 8/15/25 2:07 PM, Steve Dickson wrote:
Hey!
On 8/15/25 1:26 PM, Chuck Lever wrote:
On 8/15/25 12:23 PM, Steve Dickson wrote:
Hello,
On the more recent gcc version (15.1.1) the
-Wold-style-definition flag is set by default.
This causes
warning: old-style function definition [-Wold-style-definition]
warnings when functions are defined like
int add(a, b)
int a;
int b;
{}
instead of like this
int add(int a, int b)
{}
Now I did fix these warnings in the latest rpcbind
release... But libtirpc is a different story.
I would have to change almost every single function
in the library to remove these warnings or add I
could add -Wno-old-style-definition to the CFLAGS.
Now I'm more that willing to do the work... Heck
I'm halfway through... But does it make sense to
change the foot print of every function for a
warning that may not make any sense?
I recommend breaking up the work into several smaller
patches, and posting them here for review before you
commit.
Not quite sure how to do that... at this point it
is one huge commit... growing as we speak. Even if
I do it by file... it will still be a ton of patches.
But I agree... trying to make it easier to review
would be a good thing.
Yes, making it easier to review is exactly the idea.
Possibilities (that you are free to disregard):
- Write a cocchinele script or two?
- Ask an AI for advice on how to strategize the changes
- Change internal (non-public) functions first
- Stage the changes across several library releases
Maybe you could also pass the result through a C linter
or clang-tidy. But don't go too crazy. You get the idea.
No worries... I will not go crazy! ;-) But if I do that
God only knows what would be found! :-)
This is old code... but point taken.
Yeah, ignore the complaints about actual code. Just look at function
definitions and declarations, etc.
Out of curiosity, what is the test plan once your
conversion is code-complete?
The upcoming bakeathon?? In general I lean on the
Fedora guys to do the regression testing...
Are there critical applications or packages that build against
libtirpc? I guess... rpcbind, nfs-utils, any NIS packages left? Do you
need to build libtirpc with alternate C libraries? On alternate hardware
platforms?
autofs depends on libtirpc and I'm pretty sure there are independent
developed products that rely on TI-RPC but the the change is more
syntax than anything so I'm not sure the risk is actually high.
It's hard for me to imagine functional breakage if the code is still
compiling.
Indeed so, yes.
Ian
