On Sun, May 26, 2024 at 7:11 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Sat, 25 May 2024 12:04:46 -0500 > David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > > On 5/25/24 11:14 AM, Jonathan Cameron wrote: > > > On Fri, 24 May 2024 10:56:55 -0500 > > > David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > > > > >> On 5/20/24 11:12 AM, Jonathan Cameron wrote: > > >>> On Mon, 20 May 2024 08:51:52 -0500 > > >>> David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > >>> > > >>>> On 5/19/24 2:12 PM, Jonathan Cameron wrote: > > >>>>> On Tue, 7 May 2024 14:02:07 -0500 > > >>>>> David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > >>>>> ... > > > > Maybe we are talking about two different things but calling them the same thing? > > I'm not sure. Sounds like we both think our point is entirely obvious and clearly > it isn't :( > > > > Key is the complete lack of > > > association between what is returned by the get_current_scan_type() callback > > > and this ext_scan_type array. > > > > Why would the caller of get_current_scan_type() need to know that the > > returned value is associated with ext_scan_type? > > Because you are validating ext_scan_type, not the return of get_current_scan_type(). > They may or may not include the same data - to make this a good interface, that isn't > error prone, get_current_scan_type() must return one that has been validated - i.e. > is in the ext_scan_type array. > > I've looked several times and maybe I'm just failing to spot what ensures the validation > is sufficient. > Ah, I finally get it now. I was having tunnel vision and it didn't even occur to me that someone might be tempted to return anything that wasn't a pointer to the ext_scan types array. > > > > > > > > So either: > > > 1) Make it do so - easiest being to return an index into the array rather than > > > a possibly unrelated scan_type - > > This option 1) makes sense to me now. Do we also need to validate that the index returned is < num_ext_scan_types in iio_get_current_scan_type()?
