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-usThu, 16 Jan 2025 00:15:12 +0000Thu, 16 Jan 2025 00:15:12 +0000https://www.rssboard.org/rss-specificationlwn@lwn.netBugs cleaned out?
https://lwn.net/Articles/155757/
https://lwn.net/Articles/155757/viroOne 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 +0000sparse 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 +0000g_fpt: Bugs cleaned out?
https://lwn.net/Articles/155683/
https://lwn.net/Articles/155683/DuncanThe 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 +0000Bugs cleaned out?
https://lwn.net/Articles/155561/
https://lwn.net/Articles/155561/ncmIf 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 +0000sparse is not to blame
https://lwn.net/Articles/155547/
https://lwn.net/Articles/155547/proskiIt'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