On Thu, Dec 18, 2014 at 02:58:38PM -0700, Andreas Dilger wrote: > > It is really a bad idea to be using a feature bit that isn't at least > _registered_ in e2fsprogs, even if the full support isn't there, since > you run a real risk of someone else using that feature bit for some > completely different feature, and mass problems may result (e.g. e2fsck > incorrectly thinking it understands the feature when it doesn't). Well, it can happen if you are fuzz-testing. The other possibility is that I happen to know that the version of e2fsprogs that Wade was using is rather old, for hysterical reasons. (We should fix this, and in fact there had been some suggestions that we fix this for other reasons, but we've just not gotten around to it.) > > I can do either, if you insist. What would you prefer: > > > > a) Statically defining the various FEATURE_foo strings, as you describe. > > b) Duplicating the implementation of the two functions so that > > e2p_feature2string() can retain its prior behaviour of returning a > > string constant in the common cases. A third possibiltiy is to change e2p_feature_to_string to only use the passed-in buffer if it is given an unknown feature, but other times, it will return a static constant string, just as e2p_feature2string does today. That is, change the contract of e2p_feature_to_string such that the buffer MAY be used by e2p_feature_to_string, instead of MUST be used.... I believe I've seen other cases where the foo_r() version of a foo() function works in this way; the passed-in buffer is used if it's necessary for thread-safety, but it is not guaranteed that the buffer is used; only that foo_r() is thread-safe. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
