On Mon, March 3, 2008 12:56 am, Phil Dibowitz wrote: > Stephen Warren wrote: >> Well, it is true that internally the library knows this. However, I >> don't see a reason the application shouldn't be "allowed" to know this >> information too; perhaps the application wants to copy the data or save >> into some application specific buffer. For this reason, I think we >> should expose length here too (and check it ==FIRMWARE_SIZE when passed >> back in for safety.) > > I'm not sure I agree. We already provide a way of saving this data: > write_firmware_to_file() and write_safemode_to_file(). That array is > simply > an opaque data object to the library. I want to be able to change it > without > breaking the API, and if possible, the ABI. The user shouldn't touch it. > Heck, they don't even need to know it's an array - it's just a pointer to > them.
Well, in that case, it should be a "void *" not a "uint8_t *", to indicate explicitly that it's opaque. Either that, or I guess I'm OK with adding a get_firmware_size() API so clients can know the size. However, that still seems really inconsistent with the other APIs. Also, who says firmware blobs *have* to be the exact size of the firmware region on the device; I see no reason why a device with say 128K of firmware space couldn't contain just 119K of firmware, with the rest of the space left empty/uninitialized/... And, even if the firmware downloads from Logitech currently exactly fill the space, who says they always will; shouldn't we be checking file size <= device size, not == device size? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
