On Mon, Jun 18, 2018 at 05:56:01PM +0100, Ramsay Jones wrote: > > > On 18/06/18 05:20, Luc Van Oostenryck wrote: > [snip] > >> Hmm, I think "different restricted types" or "different restricted > >> base types" would work for all messages. > > > > There is two different cases: > > 1) '__be32' vs. 'int' > > 2) '__be32' vs. '__le32' > > Indeed. > > > In 1), __be32 is restricted while int is not. In 2) both types are > > restricted but are different restricted types. I would have a distinct > > error message for them. > > I guess I don't see a great need for different messages. In my eyes, the second case is much more critical than the first but I agree, there isn't much needs. > > BTW, I'm not at all found of the use of the word 'restricted' in the > > error message (and sparse's code) while the corresponding attribute > > is 'bitwise' and 'restrict' is an unrelated keyword since C99. > > Yes, that caused me to stumble quite often in the first few years! :) > > So, I agree it would be good to fix up the code ... > > > So maybe we should use instead "different bitwise types" and ... > > "different bitwiseness"? ;) > > ... and my only concern with new wording in the messages - would > this cause kernel developers to double take? (non-kernel developers > would most likely not be affected, since they don't use 'bitwise' > types anyway). Yes, I suppose too that 'bitwise' is only/mainly used for the kernel. I also suppose that some, maybe most, kernel devs would welcome the change > Having said that, I much prefer something like: > > 1) "mixing 'bitwise' and normal types" > 2) "different 'bitwise' types" > > Or, something like that. ;-) That's sound good and is not to long. I would just use 'plain' instead of 'normal' because ... normally I don't use the word 'normal'. I'll keep this change with the new wording but I won't apply it soon. Same for the change in the code. Thanks for the opinion and suggestion. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
