> > * Can we adopt on principle removing all cpp guards on protos? > Why would this be a good idea? > What does "cpp guards" actually refer to?
Upon re-reading this I *think* what they mean is stuff like #if CONFIG(SOME_OPTION) void function_prototype(void); #endif and not what I'd usually call "header guards": #ifndef THIS_FILE_H #define THIS_FILE_H ...file contents #endif /* THIS_FILE_H */ Cleaning up the former sounds reasonable to me, we already tend to avoid that for new code because it's just less clutter without really causing a problem (declaring extra prototypes don't hurt anyone), and it avoids problems with code that is unreachable but still compiled when CONFIG_SOME_OPTION is disabled. > Guys, it is a bit tricky to prevent discussions in a call when someone brings > up a topic, and I'm not sure that blocking that is useful. The meetings are > open and particularly people commenting here have been invited to the calls. > Please make use of that opportunity and join, if you think that you have a > strong opinion. I think I got a bit spooked because the minutes were hard to understand and the "no decision made for now" sounds like another big change to how we are writing code at the moment might be coming down there in the future. If it's just a cleanup to conform to what has mostly been recent practice anyway it's not that big of a deal. In general I think it's fine if you discuss things on the call as they come up, but if you notice that it's something that would interest the community at large (e.g. proposed style changes) it would be nice if you could summarize any discussion/opinions you had in an email afterwards and then continue further discussion on the mailing list. I guess that's somewhat what these minutes are, they were just a little unclear in this case (and it would probably better to have a separate topic for things of wider interest). _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
