LWN.net Logo

The __nocast attribute

Attentive readers of patches being merged for 2.6.12-rc2 will have noticed the use of a new attribute: __nocast. For example, the prototype of kmalloc() has changed to:

    void *kmalloc(size_t size, unsigned int __nocast flags);

For normal compilation, this attribute expands to an empty string; it has no effect. When the sparse tool is being used, however, the __nocast attribute disables many of the implicit type conversions performed by the compiler. In the kmalloc() case, sparse will complain whenever a signed integer value is passed as the flags argument. Since the GFP flags passed to kmalloc() are explicitly defined as unsigned values, they will not cause a warning to be issued. Any normal integer variable or constant, however, will be flagged. Similarly, the use of an integer value where an enumerated type is expected will be caught. Thus, this little tweak should help with the automated detection of another class of errors that the compiler will not find.


(Log in to post comments)

The __nocast attribute

Posted Mar 31, 2005 4:44 UTC (Thu) by iabervon (subscriber, #722) [Link]

Does this also prevent an size_t value from being sent as an unsigned int in cases when size_t is a typedef for unsigned int? If so, it would prevent the error of swapping the arguments to kmalloc in cases where a chunk of 128 bytes is needed with GFP_KERNEL, and instead 208 bytes are allocated using filesystems but not I/O or waiting.

The __nocast attribute

Posted Mar 31, 2005 16:27 UTC (Thu) by joern (subscriber, #22392) [Link]

__bitwise would be the attribute for what you describe.

The __nocast attribute

Posted Mar 31, 2005 17:38 UTC (Thu) by iabervon (subscriber, #722) [Link]

__bitwise would also be appropriate, and I'm actually fairly surprised that kmalloc doesn't have it already, but there are also applications for a distinction between size of element and number of elements, which a __nocast that made your size_t arguments have to come from size_t variables (or sizeof expressions, more often) would catch.

Fixing a problem that shouldn't be

Posted Apr 8, 2005 4:35 UTC (Fri) by etrusco (guest, #4227) [Link]

Again and again and again: I can't believe (so many) people prefer to play these catch-and-run (*) games rather than use a strong typed language...

(*) I agree I'm lacking a proper metaphor ;) But as you may have noticed English isn't my native language...

Fixing a problem that shouldn't be

Posted Apr 9, 2005 11:15 UTC (Sat) by fergal (subscriber, #602) [Link]

While I dislike C and like strongly typed languages, I'm kinda curious which particular pan-platform, strongly typed langauge you'd recommend for the rewrite of >100MB of hardware banging source code?

Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds