On 09/17/2013 04:13 AM, David Rientjes wrote: > On Mon, 16 Sep 2013, Chen Gang wrote: > >> Hmm... I am not quite sure: a C compiler is clever enough to know about >> that. >> >> At least, for ANSI C definition, the C compiler has no duty to know >> about that. >> >> And it is not for an optimization, either, so I guess the C compiler has >> no enought interests to support this features (know about that). >> > > What on earth are we talking about in this thread? > ?? > Rename mpol_to_str() to __mpol_to_str(). Make a static inline function in > mempolicy.h named mpol_to_str(). That function does BUILD_BUG_ON(maxlen < > 64) and then calls __mpol_to_str(). > > Modify __mpol_to_str() to store "unknown" when mpol->mode does not match > any known MPOL_* constant. > Can we be sure 'maxlen' should not be less than 64? For show_numa_map() in fs/proc/task_mmu.c, it use 50 which is less than 64, is it correct? > Both functions can now return void. > > This is like a ten line diff. Seriously. > > Can we be sure that our output contents are always less than 64 bytes? Do we need BUG_ON() instead of all '-ENOSPC' in mpol_to_str()? Hmm... If assume what you said above was always correct: "we are always sure 64 bytes is enough, and 'maxlen' should be never less than 64". It would be better to use a structure (which has a member "char buf[64]") pointer instead of 'buffer' and 'maxlen'. (and also still need check 64 memory bondary and '\0' within mpol_to_str). Thanks. -- Chen Gang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>