Phil Dibowitz wrote: > Stephen Warren wrote: >> int read_safemode_from_remote(uint8_t **out, lh_callback cb, >> void *cb_arg); > > Ah. OK, I know why it would never occur to me to do this. This is always > FIRMWARE_SIZE. We can surely return the size, but the library *ALWAYS* knows > the size, so it's rather silly to do this. We'll be passing the user a value > for them to pass back that we know already. In fact, if it's not > FIRMWARE_SIZE, something's wrong. So I see no need to this.
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 guess we could always expose a get_firmware_size API, but I think it's better to explicitly pass the size in/out of each function call, so the size is attached to a specific buffer. For the Z-Wave remotes (or whatever remotes the website sends back .zip files in Kevin's package of downloads/dumps) it looks like there are multiple update/firmware blobs in a single package, so there won't always be a single FIRMWARE_SIZE in a given session... >> Well, I guess we could mmap. That might make the code less portable if >> the API requires a mmap-style implementation, rather than simply allows >> it. That said, this detail can probably be hidden - we'd either have >> > <SNIP> >> If the API did allocate anything internally (e.g. when reading from the >> remote) we'd need to make sure there was a separate free_buffer_xxx API >> for each case, so they wouldn't get confused. > > I realize my development experience is almost entirely contained in the UNIX > realm, but I was pretty sure mmap() was cross-platform. I know it's POSIX, > but I was fairly certain it was available pretty much everywhere. I > certainly don't want to handle the file differently on different platforms, > that's lame. Well, I'm pretty sure mmap() itself doesn't exist on Windows for example. Now, it's true that the same functionality is available, but the API is named something different (CreateFileMapping/MapViewOfFile for mmap and UnMapViewOfFile/CloseHandle for munmap according to a quick perusal of MSDN) ------------------------------------------------------------------------- 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
