[libgpiod]: feature request: API functions, const correctness

[libgpiod]: feature request: API functions, const correctness

[Hollerer Franz, Schrack Seconet AG, Entwicklung]

Dear libgpiod-team,

I have a request, and it would be great if you could consider it for future versions of libgpiod. Within the current API it is not obvious which function parameters are input-only parameters, and which parameter are output parameters, i.e., will be modified.

I think it would be helpful if the API is const correct. As example, I think

> struct gpiod_line_info *gpiod_chip_get_line_info(struct gpiod_chip *chip,
> 						 unsigned int offset);

should be changed to

> struct gpiod_line_info *gpiod_chip_get_line_info(const struct gpiod_chip *chip,
> 						 unsigned int offset);

making it clear that the chip object is an input parameter which is not changed by the API function. Same argument applies for many other API functions...

Thanks for consideration & Best regards,

Franz Hollerer

Re: [libgpiod]: feature request: API functions, const correctness

[Bartosz Golaszewski]

On Wed, Aug 2, 2023 at 4:06 PM Hollerer Franz, Schrack Seconet AG,
Entwicklung <f.hollerer@schrack-seconet.com> wrote:
>
> Dear libgpiod-team,
>
> I have a request, and it would be great if you could consider it for future versions of libgpiod. Within the current API it is not obvious which function parameters are input-only parameters, and which parameter are output parameters, i.e., will be modified.
>
> I think it would be helpful if the API is const correct. As example, I think
>
> > struct gpiod_line_info *gpiod_chip_get_line_info(struct gpiod_chip *chip,
> >                                                unsigned int offset);
>
> should be changed to
>
> > struct gpiod_line_info *gpiod_chip_get_line_info(const struct gpiod_chip *chip,
> >                                                unsigned int offset);
>
> making it clear that the chip object is an input parameter which is not changed by the API function. Same argument applies for many other API functions...
>
> Thanks for consideration & Best regards,
>
> Franz Hollerer
>

Hi Franz!

No, this is not something I'm considering. The objects in the library
are all opaque. What the library does with them internally is none of
the user's business. It may want to modify the structs for some
internal tracking for all you know.

Doxygen docs in the headers are pretty clear on what argument is used
for what IMO.

Bartosz

RE: [libgpiod]: feature request: API functions, const correctness

[Hollerer Franz, Schrack Seconet AG, Entwicklung]

Hi Bartosz!

I hesitate to follow your reasoning. I personally highly appreciate const correctness as it IMHO makes the intend of the code clearer, prevents misuse, and gives the compiler more options for warnings and optimization.

Anyway, it's your choice and I respect this.

Franz

Re: [libgpiod]: feature request: API functions, const correctness

[Bartosz Golaszewski]

On Mon, Aug 14, 2023 at 10:16 AM Hollerer Franz, Schrack Seconet AG,
Entwicklung <f.hollerer@schrack-seconet.com> wrote:
>
> Hi Bartosz!
>
> I hesitate to follow your reasoning. I personally highly appreciate const correctness as it IMHO makes the intend of the code clearer, prevents misuse, and gives the compiler more options for warnings and optimization.
>
> Anyway, it's your choice and I respect this.
>
> Franz
>

If your object is:

struct foo {
    int foo;
    unsigned int bar;
};

And you know that after the call to do_stuff(), it will be the same,
then it's perfectly reasonable to go: void do_stuff(const struct foo
*f);.

But if all you have is:

struct foo;

And you have no idea what do_stuff() does internally, then (as the
author of the library) you're limiting yourself for the future if you
suddenly need to do: foo->counter++ in do_stuff().

In C++ this is fine - even if your method is marked as const, you can
have fields marked as mutable if they don't change the "logical
constness" of the object but in C it's better to just not use const
with opaque types.

Bart