On Mon, Apr 14, 2008 at 04:43:20AM -0400, Jakub Jelinek wrote:Actually, how hard would it be to allow new modifiers recognized by format string checking? Hell, even being able to teach it that (in this family of functions) "%<d>u" should expect dma_addr_t, "%016<64>x" - u64, etc. would solve all the problems. Ideally we'd need something for things like IPv4 address (__be32 expected), IPv6 address (taking __be32 *), etc. No magic, usual calling conventions - it'd still remain a valid C. We can do that in sparse and just tell gcc to STFU about these warnings, of course, but that's kind of things that is probably wanted by userland projects as well... BTW, ISTR FreeBSD folks carrying gcc patches in their tree for something with similar purpose - project-specific format modifiers/specifiers. No idea how hard it would be to generalize, though - never looked at those in details... --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| David Newall | Re: Slow DOWN, please!!! |
| Peter Zijlstra | [PATCH 00/23] per device dirty throttling -v8 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
