Re: [Libtirpc-devel] -Wold-style-definition warnings

[Ian Kent <ikent@redhat.com>]

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