|
It sounds like your concern is that if the caller of the public function nsfb_set_geometry() passes in certain arguments, they can invoke undefined behavior, because the function doesn't correctly handle the case where the desired framebuffer is larger than 256 mebibytes (assuming 32-bit ints), and it may suffer an integer arithmetic overflow. That doesn't seem very surprising; nearly any function in C can be crashed by passing it invalid arguments. For example, printf((char)37), free((char)main), or memcpy(argv[0], argv[1], 10485760). Perhaps your concern is that the 256-mebibyte limitation isn't documented? libnsfb in general has very little documentation; this is the only documentation I see for nsfb_set_geometry(): /** Alter the geometry of a surface
*
* @param nsfb The context to alter.
* @param width The new display width.
* @param height The new display height.
* @param format The desired surface format.
*/
int nsfb_set_geometry(nsfb_t *nsfb, int width, int height, enum nsfb_format_e format);
The README says: API documentation
-----------------
Currently, there is none. However, the code is well commented and the
public API may be found in the "include" directory. The testcase sources
may also be of use in working out how to use it.
So I would say that, if you're concerned about documentation, there are much greater deficiencies in documentation than the documentation of this particular limitation.Perhaps your concern is that 256 mebibytes is actually a reasonable size for a framebuffer, not an invalid argument? With the 32-bit formats all modern displays seem to use, that would be 8192 × 8192. That seems like a colorable argument; I've worked with some images larger than that since last millennium. But it still seems serviceable for most purposes. With 16-bit ints, it could fail if the framebuffer was larger than 4096 bytes, which seems like a more serious problem, but I don't know if libnsfb can be built on 16-bit and 8-bit platforms. |