Hi Alan,
Thank you for the information. However, for my case, it's passed through
function parameters.
For example, let's say it's a helper function to read mem[2]. `mem` in this
case is a function argument. It isn't reassigned, so the pointer is a
const, and it isn't used to modify the underlying memory, so that's const
as well. So:
uint8_t helper(FAR const uint8_t * const mem)
{
return mem[2];
}
`mem` depends on the usage, but is not a compile time constant (like, say,
we get `mem` from a malloc).
This is an overly simplified case, but I have heard that const helps in
optimizations.
Regards,
Saurav Pal.
On Fri, Jul 12, 2024 at 6:28 PM Alan C. Assis <acas...@gmail.com> wrote:
> Hi Saurav,
>
> I don't know why it is not much used, maybe Greg or Xiang have some idea.
>
> I think the most common use of const for variables that you want to keep in
> flash to avoid keeping it in RAM (to save RAM space for MCU with low RAM
> memory).
>
> The side effect on this case is Flash access is slower.
>
> BR,
>
> Alan
>
> On Thu, Jul 11, 2024 at 3:16 PM Saurav Pal <resyfer....@gmail.com> wrote:
>
> > Hi all,
> >
> > Suppose I have a pointer that I want to pass through function parameters.
> > In the function, neither is the pointer reassigned, nor is the thing it
> > points to modified in any form.
> >
> > So, I would assume its function argument signature to be like FAR const
> > struct my_struct * const ptr (The second "const" is my focus here).
> > Similarly for things like const uint8_t my_num, etc. as well.
> >
> > However, I have not really seen much use of specifying constants using
> > const (in the way I have mentioned above). Most of the examples I see are
> > of FAR const struct my_struct * ptr. I have heard the compiler can make
> > better optimizations for const, and because of this, I try to spam const
> > anywhere and everywhere I can. But I don't see too many such usages
> across
> > the codebase, so I was wondering why that is (or I just maybe reading the
> > code wrong, in which case, forgive me 🙏).
> >
> > Regards,
> > Saurav Pal.
> >
>
