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?
It's hard for me to imagine functional breakage if the code is still
compiling.
--
Chuck Lever
