Stephen Warren wrote: > Phil Dibowitz wrote: >> What about passing around a void* like I suggested with the size and all >> hidden inside of but an export_blob() API that dumps it to something easy - >> such as our uint8_t* with a size, and of course an import_blob() to go with? >> Initially this will be kinda of silly because the internal representation >> will be identical, but it gives us the freedom to change at will and the >> flexibility to let users hack on stuff. >> >> FURTHER, it means they'll never screw with OUR copy of the data - they have >> to *ask* us to take it via import_blob(), so we can do some sanity checking >> and such if we'd like. > > Yeah, I guess that would work. > > So I guess we'd end up with something very roughly like: > > // could read() or mmap() > read_blob_from_file(filename, out_blob) > // create blob referencing (or taking copy of) user-supplied data > make_blob_from_data(data, size, out_blob) > // copy data from blob into new buffer > copy_data_from_blob(blob, out_data, out_size) > // must know which API created it, to know how to destroy it; > // kinda like a virtual destructor > destroy_blob()
Why would we need to know which API created it? The whole reason for having
an import/export mechanism is so that the blob is always the same.
Hmm - OK, well if it was mmap()d, we'd have to close the file descriptor,
but that's easy enough: if (blob->fd) {...}
I see the API keeping closer to its current naming conventions:
read_file(filename, lc_blob)
import_blob(data, size, lc_blob)
export_blob(lc_blob, data, size)
delete_blob(blob)
And everything else staying same as it is now, except that instead of taking
uint8_t* and uint32_t, it just takes void*.
> In other words, extract_firmware_binary would be folded into the
> internal implementation of write_firmware_to_remote, and similar for
> find_config_binary/write_config_to_remote?
Hmmm. Yeah, I guess. Do we still pass around binary flags then? Yes, I guess
we do. But originally I had envisioned export_blob() and import_blob() to
operate entirely in binary mode. Would there be any reason for them not to?
If so, would we then need the extract_*() functions then?
--
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
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
