> The only thing I consider worth changing is to rename the > whole stuff from 'fixed buffer interface' to 'locked buffer > interface', which makes more sense at the current state. Agreed. Sorry if I missed this before, but: > If the object never resizes or reallocates the buffer > during it's lifetime, this function may be NULL. Failure to call > this function (if it is != NULL) is a programming error and may > have unexpected results. Not sure I like this. I would prefer to put the burden of "you must provide a (possibly empty) release function" on the few buffer interface implementers than the many (ie, potentially any extension author) buffer interface consumers. I believe there is a good chance of extension authors testing against, and therefore assuming, non-NULL implementations of this function. OTOH, if every fixed buffer consumer assumes a non-NULL implementation, people implementing this interface will quickly see their error well before it gets into the wild. No biggie, but worth considering... Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4