Ok, Geo. I'm convinced.

Look in the CVS for owcapi. (libowcapi.so.0.0.0)

Very simple library:
int OW_init( const char * device ) ;
int OW_get( const char * path, char * buffer, int buffer_length ) ;
int OW_put( const char * path, const char * buffer, int buffer_length ) ;
void OW_finish( void ) ;

Seems to work.

Paul

On Tuesday 11 October 2005 04:44 pm, Geo Carncross wrote:
> On Fri, 2005-10-07 at 14:06 -0400, Alfille, Paul H.,M.D. wrote:
> > Sven,
> >
> > It would be easy to do. The real problem is string handling. We'd have to
> > specify buffers and lengths.
>
> Why?
>
> int get_value(const char *path, char **ret, unsigned int *retlen);
>
> Would be adequate and not require a buffer, and if everything is
> ASCIIZ-safe, using:
>
> int get_value(const char *path, char **ret);
>
> would be fine too.
>
> > So for a directory listing, you would get either a long string to be
> > parsed, or an array of strings.
>
> Why not a pointer to an array and a list?
>
> Or an iterator? [think about how opendir() works]
>
> > Also, the return types are multiple, integer, string or floating. It
> > would probably be better to get the raw data type rather than have to
> > reparse the ascii interpretation.
>
> Why would it? That just makes it complicated.
>
> Since it's already in the string form, parsing it again for me doesn't
> help. After all, I might be able to get by with something that becomes
> equivelent to:
>
> unsigned int q = *(unsigned int*)ret;
> if (q&255) { /* must not be a three-digit number */ }
>
> The user already knows how to use atoi(), and if they want to use it,
> this really won't cost them a lot in cpu-time. Nothing compared to
> context-switches and the fact that 1wire is already really slow :)
>
> > Choices in C:
>
> I think the real-deal is avoiding the context switches and
> code-complexity.


-------------------------------------------------------
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

Reply via email to