On 8/15/25 2:18 PM, Chuck Lever 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
This might be a good idea... But I'm thinking of grouping
the commits by functionality... commit src/clnt_* files
then src/pmap_* file etc... I'm thinking there would be ten
or so patches... I'll see what it looks like.
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.
True.
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?
It's hard for me to imagine functional breakage if the code is still
compiling.
I agree... My carpal tunnel syndrome might acted up
do to all the repetitive typing ;-) This should be
straightforward... just a lot of change.
steved.
