XPost: alt.folklore.computers, alt.unix.geeks
From: bowman@montana.com
On Thu, 08 Jan 2026 19:16:38 GMT, Charlie Gibbs wrote:
> On 2026-01-08, The Natural Philosopher wrote:
>
>> On 07/01/2026 22:49, rbowman wrote:
>>
>>> On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:
>>>
>>>> It is possible that current C compilers signal many more problems
>>>> that back then, but not runtime errors.
>>>
>>> gcc has become pickier. That isn't always a welcome thing when working
>>> with legacy code and requires a search of the compiler options to get
>>> it to shut up about such horrible heresies as assuming a function
>>> returns an int.
>>>
>> Actually I welcome that. at leats 10% of the time the compiler finds a
>> bug that way, and the other 90% i upgrade the source to be more
>> explicit...
>
> +1
>
> I re-worked my code over time so that -Wall yields no errors.
> And then a new version of gcc comes out which picks even more nits, and
> the process repeats. Not being a quick-and-dirty type, I consider it a
> win overall.
>
> The one exception is its scrutiny of printf() calls.
> That was a step too far, so I added -Wno-format-overflow.
It was never a good idea but the legacy code often defined a variable in
a .h file. The newer gcc implementations would throw multiple definition
errors. Fixing it would have been painful. foo.h that defined int bar;
might be included in several different programs so you would have to hunt
down all the uses and then define bar someplace in a .c file.
Great project for the new guy but at the time the newest guy had been
there for 20 years. Adding the compiler flag to the relevant makefiles was
easier.
The missing int return type in function definitions wasn't as widespread
and an easier fix. It was sort of pedantic since the return usually wasn't
being checked anyway.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
