On Thu, Nov 18, 2021 at 7:22 PM zack leung <zakthertems...@gmail.com> wrote: > > bump > > On Mon, 18 Oct 2021 at 23:58, zack leung <zakthertems...@gmail.com> wrote: > > > bump > > > > > > On Sat, 25 Sept 2021 at 00:26, zack leung <zakthertems...@gmail.com> > > wrote: > > > >> bump > >> > >> On Thu, 9 Sept 2021 at 02:17, zack leung <zakthertems...@gmail.com> > >> wrote: > >> > >>> >Thanks! I guess i'm really unsure about how the pointer relates to the > >>> amount of memory that you can use. I assume the Malloc keeps track of the > >>> sections being used in the heap. Does this function Allocate 2 blocks > >>> since > >>> the pointer is set to > >>> > >>> (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin; > >>>
No, this is calculating the size of 'this block' considering that it's allocated memory starts at "alloc_begin" and it ends at the "next_block" heap block metadata or header. You should read about how malloc implementations generally work. The allocated memory has some metadata before it to implement the linked data structures necessary to support dynamic allocation. So a block is the header + allocated range. Only the allocated range plus any excess before the next block's header is considered usable. > >>> >(I know it's a bit naive to assume this given my first question) > >>> > >>> think the method is _Heap_Size_of_alloc_area. It may need a wrapper > >>> added to the protected heap wrapper for safety. I don't know if it has > >>> one. > >>> It should be the equivalent functionality. > >>> > How would i implement a wrapper and what safety measures need to be > >>> implemented. So far it's checking if : the block is not in the heap and > >>> if > >>> it's been previously used. Is the usable memory in the heap calculated by: > >>> the size of the block * # of blocks? > >>> You would have to see if the Protected Heap implementation has some additional metadata between the end of an allocated range in one block and the block header in the next. I don't think it matters too much because most of the 'protected' aspects have to do with free block management. But that should be confirmed. The check is not "if it's been previously used" I suggest that you look at what the invoked function does and how it is documented. Avoid making assumptions based on names. The usable memory is NOT the size of the block * # of blocks, because the size of the block includes the header. > >>> Thanks, Zack > >>> > >>> ---------- Forwarded message --------- > >>> From: Joel Sherrill <j...@rtems.org> > >>> Date: Wed, 8 Sept 2021 at 20:30 > >>> Subject: Re: Ticket 4503 > >>> To: Gedare Bloom <ged...@rtems.org> > >>> Cc: zack leung <zakthertems...@gmail.com>, rtems-de...@rtems.org < > >>> devel@rtems.org> > >>> > >>> > >>> > >>> > >>> On Wed, Sep 8, 2021 at 11:02 AM Gedare Bloom <ged...@rtems.org> wrote: > >>> > >>>> Hi Zack, > >>>> > >>>> https://devel.rtems.org/ticket/4503 > >>>> > >>>> The malloc implementation exists in the score as the Heap Manager. > >>>> search for "Heap_" within cpukit to get some ideas where to look. > >>>> > >>> > >>> I think the method is _Heap_Size_of_alloc_area. It may need a wrapper > >>> added to the protected heap wrapper for safety. I don't know if it has > >>> one. > >>> It should be the equivalent functionality. > >>> > >>> newlib's malloc.h will need looking at to make sure we provide the right > >>> methods. > >>> > >>> > >>> > >>>> > >>>> @Joel are these two tickets duplicates? > >>>> https://devel.rtems.org/ticket/4503 > >>>> https://devel.rtems.org/ticket/4271 > >>>> > >>> > >>> Yes. Closed #4271 and merged comments. > >>> > >>> --joel > >>> > >>> > >>>> > >>>> > >>>> -Gedare > >>>> > >>>> On Tue, Sep 7, 2021 at 7:14 PM zack leung <zakthertems...@gmail.com> > >>>> wrote: > >>>> > >>>>> I was wondering about ticket 4503. I was wondering where The required > >>>>> functionality should be in the underlying score/ capability used can be > >>>>> found to write this function. Also how does this relate to > >>>>> > >>>>> Add common malloc family extension method malloc_usable_size() > >>>>> <https://devel.rtems.org/ticket/4271>? > >>>>> Thanks > >>>>> Zack > >>>>> _______________________________________________ > >>>>> devel mailing list > >>>>> devel@rtems.org > >>>>> http://lists.rtems.org/mailman/listinfo/devel > >>>> > >>>> > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
