Hello, I apologise for this problem, but I've been recieving emails regarding the project you are working on. However, I'm unable to understand the context of this project. But it looks exciting!
I would be thankful if you can help me through the project framework, and share the exact details, so that I can understand it and start working today itself. I would also highly appreciate if you could guide me thorugh the steps and instruct me on what I'm expected to do. I'm currently a 3rd year B.Tech-Computer Science student. Good day! Thank-you, Anaya Shah On Wed, 27 Sept, 2023, 10:16 Florian Weimer via Gcc, <gcc@gcc.gnu.org> wrote: > * Arsen Arsenović via Gcc: > > > Sam James via Gcc <gcc@gcc.gnu.org> writes: > > > >> Florian Weimer via Gcc <gcc@gcc.gnu.org> writes: > >> > >>> My understanding of the consensus goes as follows: > >>> > >>> * We want to make some changes in this area for GCC 14. > >>> * We should do the same thing that Clang does: default to the relevant > >>> -Werror= options. > >>> * Unlike regular warnings, these warnings-as-errors should also apply > >>> to system headers. > >>> * At least implict-int and implicit-function-declaration should be > >>> upgraded to errors in this way. > >>> * It's too early to make the () changes and bool-as-keyword from C2X > >>> for GCC 14. > >>> * We should fix the missing scope of the int-conversion warnings > >>> (PR109827). Likweise for incompatible-pointer-types (PR109826). > >>> > >>> Is this summary accurate? > >>> > >> > >> I wasn't there, but this reflects my understanding & what I would've > >> said if I could've attended. > >> > >>> I think the open issues are: > >>> > >>> * Do we want to implement something else beside implicit-int and > >>> implicit-function-declaration? (Candidates are int-conversion and > >>> incompatible-pointer-types, and the void vs non-void part of > >>> return-type, maybe others as previously discussed on the list.) > >> > >> Ideally, I'd like both int-conversion + incompatible-pointer-types in > >> this cycle, but if we have to defer one, I'd say to keep int-conversion. > > > > +1, this seems reasonable. I'm not sure I can imagine any even > > half-legitimate use for falling off the end of functions and similar, so > > perhaps we should also take return-type? Is that part of C23? > > Falling of the end of the function is legitimate if a no-return function > is called and not annotated as such, among other things. I don't think > we should warn or error for that by default. > > The issue I'm concerned about is about “return;” in a function not > returning void, or “return expr;” in a function returning void. This > looks like related to implict int return types for functions. It's not > part of C99. There is no separate -W switch to control this warning. > It is on by default (as required by C99), unlike other aspects of > -Wreturn-type. > > Thanks, > Florian > >
