In earlier releases, the documentation of the --suppressions option mentioned: "You may specify up to 10 additional suppression files." In valgrind-3.3.0/doc/valgrind.1 the text now says: "You may use as many extra suppressions files as you like." But this is wrong! The number is still limited to 10 in the source code. Eric Blake and I don't like arbitrary limits. In fact, GNU gnulib now has several modules with a suppressions file for each module, and the limit of 10 will hurt users soon. Attached you find a proposed patch to get rid of this limit. It is untested, so please proofread it carefully.
Created attachment 24584 [details] proposed patch
Thanks for the patch. Julian, do you think it would be a good idea to implement VG_(clo_suppressions) as an XArray ?
Redoing it using an XArray would be the best solution,although that would have the bad side effect that all modules that depend on m_options would then depend on m_xarray. Left to myself I'd be lazy and simply increase the constant number to say 100. After all It's taken 5 years for anyone to complain that VG_CLO_MAX_SFILES of 10 is too low.
Increased maximum number of suppression files to 100 in r8065. Fix will be included in Valgrind version 3.4.0.
Was anything wrong with the patch I submitted? If you leave the limit as 100, please fix the documentation, to say "You may specify up to 100 additional suppression files." The current wording "You may use as many extra suppressions files as you like." (in docs/xml/manual-core.xml line 888) is still wrong.
> Was anything wrong with the patch I submitted? * it was untested. It's a lot easier for us to increase one #define than to test your patch for you. * as per previous comments, it would be cleanest to redo your patch using the facilities in m_xarray; but then we'd have to figure out whether making lots of modules now depend on m_xarray causes any new problems. So at least from here, the 90-10 solution (90% of the benefit for 10% of the effort) is merely to increase the #define. > If you leave the limit as 100, please fix the documentation, to say > "You may specify up to 100 additional suppression files." > The current wording > "You may use as many extra suppressions files as you like." > (in docs/xml/manual-core.xml line 888) is still wrong. Yes, this is a good point. Will do. In fact, is 100 enough for you?
> Will do. Thank you. > In fact, is 100 enough for you? Yes, it solves the expected need for the next 1-2 years. When the number of individual suppressions files provides by gnulib modules increases beyond 20 or 50, gnulib-tool will anyway have to combine the suppressions files (like it now already combines Makefile.am pieces into a single Makefile.am), because otherwise the maintenance burden on the gnulib user would be too big.
Done. And merged to the 3.3 branch since the changes are pretty harmless. I'm a bit surprised you need so many suppression files. Does Memcheck really produce many false errors on your code?