On 9/21/2012 12:40 AM, Ludovic Rousseau wrote: > Hello, > > 2012/9/20 B. Scott Michel <sco...@aero.org>: >> I'm debating whether to submit a pull request on github with patches to >> reduce gcc's warnings to a minimum (actually, completely eliminated.) >> However, the patches violate the coding rules by marking unused >> parameters in static functions -- the "marking" is very explicit and >> very visible. >> >> I also took care of other issues, such as replacing "int" with "size_t" >> where needed. I should have made the unused param patch separate from >> the integer conversion and other warnings. > Do not "fix" unused param warnings. The correct way to fix them is to > remove the parameter. I think this is hard to do in the libopensc code base, since the places where unused parameters occur are in various "template" functions (i.e., functions that are pointed to by pointers-to-functions with specific prototypes.) Consequently, eliminating the unused parameters is not feasible.
I'll look into whether pointer-to-function signatures can be changed, but I'm not optimistic. > Use -Wno-unused-parameter This would require changing the automake recipes by eliminating "-Wall" and enumerating all of the beneficial warnings by hand. Doable, but ultimately not maintainable in the long term, e.g., when gcc decides to add or remove warnings from "-Wall". >> Question (and request for comments): Should I submit the pull request, >> even though the patch would potentially violate the coding conventions? > It is always a good idea to submit a pull request to be able to review it. > Maybe it will be rejected and you will be asked to change it. I'm not a fan of rejected and resubmitted patches -- I prefer to discuss first before issuing the pull request. That way, the receiver ends up understanding the intent of the patch versus reacting to the patch. Neither I nor the patch reviewer can read each others' minds, yet. -scooter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
