On Thu, 2005-10-13 at 13:49 -0400, Alfille, Paul H.,M.D. wrote: > 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.
This is fine, but needs to be documented. > Geo, you clearly have a passion for this interface. Why not do the design and > coding. You have CVS access. Oh crap, so I do. I keep forgetting what projects I'm passively passing patches through the mailing lists on and which ones I can actually step in and do things :) I did an update and cannot find the owcapi-in-progress. Is it on another tag besides HEAD? > 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. No what I mean is calls between multiple threads performing OW_get() at the same time- is OW_get() reentrant, etc. > -----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 -- 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
