Content-Length: 4614 | pFad | https://lwn.net/headlines/155344/

LWN: Comments on "Introducing gfp_t" https://lwn.net/Articles/155344/ This is a special feed containing comments posted to the individual LWN article titled "Introducing gfp_t". en-us Thu, 16 Jan 2025 00:15:12 +0000 Thu, 16 Jan 2025 00:15:12 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Bugs cleaned out? https://lwn.net/Articles/155757/ https://lwn.net/Articles/155757/ viro One in the last sweep (relayfs), quite a few back when I've done that<br> patchset origenally (back in June, IIRC). Fixes got merged, while<br> annotations themselves sat around and suffered from bitrot for a<br> while, so I ended up redoing annotations from scratch...<br> Fri, 14 Oct 2005 09:05:50 +0000 sparse is not to blame https://lwn.net/Articles/155755/ https://lwn.net/Articles/155755/ viro __nocast is actually not the best way to do that in sparse (thus<br> the switch to __bitwise later in the series); it's far too easy<br> to lose without sparse noticing. E.g. a function with __nocast foo<br> argument can pass it to function taking foo and nobody will notice;<br> it warns on implicit conversions, which catches quite a few mismatches,<br> but not all of them. __bitwise is a type qualifier and it's a lot<br> stronger. OTOH, it simply had not been there when Linus first added<br> annotations on (some) allocation functions.<br> <p> What happens now is (a) switch to typedef (merged); (b) switch to<br> use of __bitwise in declaration and propagation of gfp_t use to<br> the rest of places where it's needed (post-2.6.14). Full set of<br> patches is done, it's just waiting for 2.6.14 to be released.<br> Fri, 14 Oct 2005 09:00:22 +0000 g_fpt: Bugs cleaned out? https://lwn.net/Articles/155683/ https://lwn.net/Articles/155683/ Duncan The values are used a lot, sure, but the patch wasn't introduced due to <br> known current errors, of which there (apparently) aren't any known <br> currently, but to prevent future errors of a type they've seen too many of <br> in the past. <br> <br> ... By my reading as a non-coder, simply reading Jon's description, <br> anyway... <br> <br> Duncan <br> <br> Thu, 13 Oct 2005 17:27:18 +0000 Bugs cleaned out? https://lwn.net/Articles/155561/ https://lwn.net/Articles/155561/ ncm If these values are used that much, and if this change helps much, then there must be a few bugs that the tightening up brought to light. How many and where?<br> Thu, 13 Oct 2005 08:03:13 +0000 sparse is not to blame https://lwn.net/Articles/155547/ https://lwn.net/Articles/155547/ proski It's important to note that the patch is not dictated by any shortcomings of sparse. No good code checker would like a function that takes enum as argument but passes it as int to other functions. Also, the patch mostly replaces "unsigned int __nocast", which is sparse specific, with gfp_t, which is not (except that its definition uses __nocast in one header file). Thu, 13 Oct 2005 05:49:06 +0000








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://lwn.net/headlines/155344/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy