On 09/14/2013 05:14 AM, David Rientjes wrote: > On Thu, 12 Sep 2013, Chen Gang wrote: > >> Hmm... for extern function, at present, maybe you can guarantee, but may >> not always in the future. And "Code is mainly for making readers 'happy' >> (e.g version mergers), not writers". >> >> For extern function which more than 50 lines (used by 2 sub-systems), it >> is strange for readers to find it no return value, also strange to let >> *BUG_ON() on the extern function's input parameters directly. >> >> If one caller wants to treat failure as BUG, can "*BUG_ON(mpol_to_str() >> < 0)", that will be more clearer to all members (need this patch do like >> it? :-) ). >> >> >> BTW: in my opinion, within mpol_to_str(), the VM_BUG_ON() need be >> replaced by returning -EINVAL. >> > > Are you reading my emails? > Yes. > I'm asking for a compile-time error if the maxlen passed to mpol_to_str() > is too small; it's a constant value and can be evaluated at compile-time. > Then mpol_to_str() can return void if you simply store "unknown" when it's > an unknown mode. > Are/were you saying: 'gcc' can realize an extern functions' input parameter whether is a constant?? If so, excuse me, I really did not quite understand what you were saying, but I am still trying to understand. As far as I know: mpol_to_str() is called by 2 areas, which will input different maxlen. for a none-inline function, compiler treats parameters as variables. for ANSI C compiler, for function's parameter, "array == pointer". Hmm... maybe you see 'sizeof()'? if so, we also need notice: "multiple callers only call one callee with there different 'sizeof()'", callee has to treat these 'sizeof()' values as variable, not constant. If I am still misunderstanding, please say more with details, thanks. > Sheesh. > > 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>