-Wold-style-definition warnings

-Wold-style-definition warnings

[Steve Dickson]

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?

Thoughts...

tia,

steved.

Re: -Wold-style-definition warnings

[Chuck Lever]

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.

Maybe you could also pass the result through a C linter
or clang-tidy. But don't go too crazy. You get the idea.

Out of curiosity, what is the test plan once your
conversion is code-complete?


-- 
Chuck Lever

Re: -Wold-style-definition warnings

[Steve Dickson]

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.

> 
> 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.

> 
> 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...

But at the end of the day, I didn't realize
there would be this much change... so I have
not thought that through. Idea welcome!

steved.

Re: -Wold-style-definition warnings

[Chuck Lever]

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

Re: -Wold-style-definition warnings

[Steve Dickson]

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.

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

[Ian Kent]

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