Re: [libgpiod] Rethinking struct gpiod_line_bulk

[Kent Gibson <warthog618@xxxxxxxxx>]

On Wed, Oct 21, 2020 at 09:33:03AM +0200, Bartosz Golaszewski wrote:
> On Wed, Oct 21, 2020 at 12:24 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Tue, Oct 20, 2020 at 05:53:31PM +0200, Bartosz Golaszewski wrote:
> > > On Tue, Oct 20, 2020 at 5:06 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > >
> > >
> > [snip]
> > > > >
> > > > > I'm now actually leaning more towards making it opaque but I need to
> > > > > find a way to make gpiod_line_bulk_foreach_line work with hidden bulk
> > > > > struct.
> > > > >
> > > >
> > > > Why not just drop it in favour of gpiod_line_bulk_foreach_line_off()?
> > > >
> > >
> > > The one with the line being supplied to the user automatically is more
> > > elegant. If anything - I'd prefer to drop
> > > gpiod_line_bulk_foreach_line_off(). Callbacks as suggested by Andy is
> > > a good idea - something like what GLib does in a lot of helpers for
> > > lists etc.
> > >
> >
> > Not sure what you mean here - they both return the line, the difference
> > is how they store the loop state, with gpiod_line_bulk_foreach_line()
> > exposing the bulk->lines array via the lineptr.  That is the source of
> > your problem if you go opaque - that array becomes hidden, as it
> > probably should be.
> >
> 
> No idea what I meant either. :)
> 
> When using a function with a callback we no longer need the user to
> supply the memory for storing the loop state - it can be stored in the
> stack frame of said function - so the callback should only take the
> line as argument (+ void * user data) and the user can store the loop
> state however they like. This is how I see it.
> 

That makes sense - if you are going opaque then the callback is cleaner.

Will the callback have any return code, say to trigger a break from the
loop?

Cheers,
Kent.