[adamius]

Wrapping structs in typedefs like this should be a distant and quaint memory by now. C'mon guys its 2022. Why hasn't some standard gotten rid of this requirement for typedefs around structs?

Deprecate this requirement already and make it an option. Gcc --stupid-typedef-required

Edit: or stated in another way, please describe the good reason(s) for having typedef struct {} Foo in C. Do it in terms of justifying the extra typing / extra steps. I'd really like to know. This is extra code and one more thing to test and confirm. Don't reference history or "its just how its always been done" - that to me is an admisson that it needs to go into an option. Also you'll need to explain why its bad that C++ doesn't require this. I'd also like to see as part of this rebuttal a formal statement that C++ got it completely wrong.

So: Why in C do we require the extra steps just so we can get rid of the struct keyword having to be plastered everywhere?

Personally I think the typedef struct pattern is kept purely for historical reasons and is no longer necessary. It obscures the code rather than clarifies it. There are much better reasons for using typedef but getting rid of "struct" prefixes everywhere isn’t one of them.

[Findecanor]

Changing it would break existing code. In C, types "A" and "struct A" could have been defined as completely different types.

[adamius]

Sounds like: We've always done it this way. Often rephrased as: Its not possible to write a script to fix this. We can't have automated tests. There's no way we can find all the places this is likely to be used. There's no way to do this at all because insert-authority-figure's-opinion. Oh no! But really its all historical rather than a real issue.

Its just a code smell. There are likely other bugs hiding around the code. Business logic issues as well. Overall its a story of generally poorly written and ambiguous code. So... Perhaps fix it?

If you can't fix it then a compiler option would do it.

[duped]

That's a strawman. The reason is the option would break code due to C's semantics, in the best case it would fail to compile, and in the worst case it would still compile but change what the code did.

What you're asking for is equivalent to changing the semantics of the language, which is frankly untenable for C.

[adamius]

I'll leave it there. I respectfully agree to disagree. What to you looks like a strawman is for us a signpost towards identifying a module that needs linting and code review. Code that cannot handle that typedef change? Yeah it needs review. What other issues are hiding in there? Oh wait what have they been doing with the preprocessor?

The codebases we work on are from the 1980s. They sorely need to be dragged kicking and screaming if necessary to later standards. So many warts. People abused the preprocessor like it was normal and expected.

The semantic change isn’t as big as you'd expect. Even as it is in fact a semantic change. But I sense significant gatekeeping as well to hold back the tide.

[Cloudef]

https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

[adamius]

If you can't figure out what vps_t means in your codebase then you have much much bigger issues than typedefs.