Resource freeing functions should generally be safe to call with NULL pointers.
Why?
- there is some precedence in the kernel for this for deallocation functions.
- removes the need for callers to check pointers for NULL.
- space is saved overall by less code to test pointers for NULL all over the place.
- removes possible NULL pointer dereferences when a caller forgot to check.
This patch makes fb_dealloc_cmap() safe to call with a NULL pointer argument.
Signed-off-by: Jesper Juhl <redacted>
---
drivers/video/fbcmap.c | 3 +++
1 files changed, 3 insertions(+)
From: Jon Smirl <hidden> Date: 2005-07-17 20:22:51
On 7/17/05, Jesper Juhl [off-list ref] wrote:
Resource freeing functions should generally be safe to call with NULL pointers.
Why?
- there is some precedence in the kernel for this for deallocation functions.
- removes the need for callers to check pointers for NULL.
- space is saved overall by less code to test pointers for NULL all over the place.
- removes possible NULL pointer dereferences when a caller forgot to check.
This patch makes fb_dealloc_cmap() safe to call with a NULL pointer argument.
The fb cmap copde would be a lot simpler if it did everything with a
single allocation instead of five. Make a super cmap struct:
struct fb_super_cmap {
struct fb_cmap cmap;
__u16 red[255];
__u16 blue[255];
__u16 green[255];
__u16 transp[255];
}
Then adjust the code as need. Have the embedded cmap struct point to
the fields in the super_cmap and the drivers don't have to be changed.
--
Jon Smirl
jonsmirl@gmail.com
Resource freeing functions should generally be safe to call with NULL pointers.
Why?
- there is some precedence in the kernel for this for deallocation functions.
- removes the need for callers to check pointers for NULL.
- space is saved overall by less code to test pointers for NULL all over the place.
- removes possible NULL pointer dereferences when a caller forgot to check.
This patch makes fb_dealloc_cmap() safe to call with a NULL pointer argument.
The fb cmap copde would be a lot simpler if it did everything with a
single allocation instead of five. Make a super cmap struct:
struct fb_super_cmap {
struct fb_cmap cmap;
__u16 red[255];
__u16 blue[255];
__u16 green[255];
__u16 transp[255];
^^^
I assume you meant 256?
}
Then adjust the code as need. Have the embedded cmap struct point to
the fields in the super_cmap and the drivers don't have to be changed.
What if your colormap has more than 256 entries?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
}
Then adjust the code as need. Have the embedded cmap struct point to
the fields in the super_cmap and the drivers don't have to be changed.
What if your colormap has more than 256 entries?
I meant 256. Does any hardware exist that takes more that 256 entries?
They are __u16 values but I have never seen hardware that take more
that __u8 either.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
}
Then adjust the code as need. Have the embedded cmap struct point to
the fields in the super_cmap and the drivers don't have to be changed.
What if your colormap has more than 256 entries?
I meant 256. Does any hardware exist that takes more that 256 entries?
1024 was quite common on high-end graphics hardware.
They are __u16 values but I have never seen hardware that take more
that __u8 either.
10 bit was quite common on high-end graphics hardware.
IIRC, DEC TGA can do at least one of them.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click