Stephen Warren wrote: >> which we make a pointer to and cast it to a void* and passed back to the >> user? This way we can make firmware, safemode fw, and config APIs all >> "look" the same? > > I guess hiding size in all cases is fine. > > However, we'd then need to completely remove find_binary_size and > find_binary_start from the libharmony API, and have the library do > whatever it needs to internally.
You are correct. Good call. > We have no idea if the EZHex file will always contain exactly > FIRMWARE_SIZE bytes; to be completely robust, we shouldn't fail if it > contains less bytes, because they choose not to send unused bytes. Hmmm. I see you're point. I was looking at it the other way: if the "spec" (we don't have one, but clearly they use one somewhere) says that no firmware file is valid unless it's exactly 128k, we should honor that. But upon further thought, I think I like your approach better. Particularly when you consider we erase_firmware() first anyway (although I don't know if they use the same kind of flash in the zwave remotes... but we'll cross that bridge when we come to it). OK, I'm convinced that the code should be dynamic. And given that, and that we have the find_binary_start() stuff... lets go the easy route and do what you originally purposed - pass back a size. *BUT* only if the code is *actually* dynamic. That means we get rid of FIRMWARE_SIZE, and make it FIRMWARE_SIZE_MAX and just check we're not bigger than that. -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
