The extra null byte should be invisible. You have the length of DATA returned as the function results (and buffer_length), but if you lazily just use the results as a string, the extra null byte should protect the rest of memory.
Geo, you clearly have a passion for this interface. Why not do the design and coding. You have CVS access. I'm lost in the "crappy threading model". owlib would not like multiple init's or finishes, but the library regards simultaneous access via owcapi the same as simultaneous access over the filesystem interface, or the server model. There a mutexes protecting the physical devices, as well as important data structures. Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Geo Carncross Sent: Thursday, October 13, 2005 12:06 PM To: owfs-developers@lists.sourceforge.net Subject: RE: [Owfs-developers] New owcapi interface. Happy? On Thu, 2005-10-13 at 11:21 -0400, Alfille, Paul H.,M.D. wrote: > Very nice work. > > Actually, OW_get is always null-terminated (we add an extra byte to the > allocation and zero it), but not all values are strings (like memory from > devices like the DS1993 are arbitrary data). In these cases, is it then wise to null-terminate? Should the programmer really be expected to remove (or ignore) that null byte? Perhaps two calls: OW_get() which accepts two parameters (and assumes null-terminate) OW_get_binary() which takes three and does no null termination? I still think: OW_get_buffer() with four parameters (mirroring FS_read()) is a good idea. The OW_get_binary() and OW_get() can target it (instead of touching FS_read() directly) I'm happy to put together reasonable examples/documentation for these things. > I believe owcapi is tread-safe. Certainly the underlying owlib is. owcapi has no > global variables so should be tread safe. It might be safe to use with threads, but there's an underlying ofile there someplace, and two writes at the same time could collide the same as using interleaved writes to a fifo. With the SQLite project, lots of people get confused on this issue. I never would have believed it possible unless I had seen it myself, but people frequently mistake thread-safe with use-whatever-crappy-threading-model-you-like. > Calling OW_get before OW_init should return an error, I'll put in a check on > "indevices" which will show if there are any valid devices configured. Calling > OW_init implicitly would not work, since the "device" is not known (I know, the > use of a environment variable is possible). :) Is the error reported useful? Is errno set? Can it be? Many APIs chose to implement their own error handling; I'm happy overloading errno, but that die() function relies on errno being useful. If OWDEVICE is unset, and NULL is specified (as recommended!) then what gets printed? What will the user of this program see? How will they be helped? > Not calling OW_finish isn't terrible. You just can't call OW_init again, I bet. > It is the functional equivalent of "free"ing memory after use. The process death > should reclaim the memory as well. Bah. I look in some of my source, and it looks like more than 99% of the time, I simply ignore calling free() expecting the operating system to toss the pages when exit is called. I encourage others to do the same- because there is tons to worry about- and all that extra code that doesn't do anything just serves to introduce more attention to things that aren't causing problems, and (in practice) takes away attention from the things that could :) -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/ ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
