On Tue, Oct 19, 2010 at 12:27 AM, Shaya Potter <[email protected]> wrote:
> On 10/19/2010 12:18 AM, Rocky Bernstein wrote: > >> >> I don't see any reason right now to hide anything in udf_dirent_s, so >> the simplest thing is to expose all of it. If you are imagining other >> things in struct stat that aren't in udf_dirent_s, well, they aren't >> readily available as the start block and length are. >> >> >> For instance, I couldn't write udf_get_start_block() easily outside >> of libudf, because I needed offset_to_lba(). >> >> >> Yes, so that would be made public too. >> >> >> As mentioned, part of me thinks a well thought out udf_stat() >> function is what's needed. >> >> >> Ok. Suggest something. Or better, implement it. >> > > I'm mostly worried about ABI issues. there's a reason the stuff was > private in the first place and keeping it there helps with not having to > version the shared lib. > True for API, but not ABI. Any time the private structure changes the ABI changes. The library has to be versioned in either case. > > I'll look into it, though right now, trying to convert my dvd iso > decrypting program into instead of writing out a new file, do it all in > place (relatively simple, but its only a night time endeavor) > Ok. Thanks. No rush on this side.
