I think that the malloc tests is calculated differently than  alloc_size+
allocsize mod it looks like this
 *alloc_size = (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
when i run the comparison  i get 8 (with heap alignment) and the function
gives me 12.
 is the heap alloc bonus part of the current block?

On Thu, 6 Jan 2022 at 21:28, Joel Sherrill <j...@rtems.org> wrote:

> On Thu, Jan 6, 2022 at 2:55 PM Gedare Bloom <ged...@rtems.org> wrote:
> >
> > On Tue, Jan 4, 2022 at 6:10 PM zack leung <zakthertems...@gmail.com>
> wrote:
> > >
> > > Helllo  ,
> > > I'm working on a patch for malloc_get_usable size right now so far i
> have
> > > this test case for malloc, I just make sure that the value is null and
> i
> > > just malloc an int and then  i make a call to the function
> malloc_usable
> > > size and then i compare it like this.
> > >
> > > static void test_malloc_usablesize( void ){
> > >    int * a = malloc(sizeof(int));
> > >    rtems_test_assert((int) malloc_usable_size(a) == 12);
> > >    free (a);
> > >
> > >    int * b = NULL;
> > >    rtems_test_assert( 0 == malloc_usable_size(b));
> > >    free(b);
> > >
> > >
> > > }
> > > Is there a good amount of storage to allocate? Also I heard someone
> made a
> >
> > I think that this test case is quite brittle. The "usable size" will
> > depend on the implementation details of malloc, and the conditions of
> > the heap when the allocation request gets made. I don't have better
> > ideas however for how to test the correctness of the usable_size
> > function. Maybe there are certain sequences of malloc/free calls that
> > can be relied upon to give you deterministic sizes of allocations?
>
> My suggestion in private chat was that you can depend on the
> malloc heap being initialized with CPU_HEAP_ALIGNMENT. That's
> what that macro is specifically for. It is used in
> include/rtems/score/wkspaceinit*.h
> and has been since the dawn of time.
>
> Then the size for a valid pointer from malloc() should be between
> the allocated size and the next number on a CPU_HEAP_ALIGNMENT
> boundary. I think the exact number is actually something like this:
>
> expected = alloc_size;
> mod = alloc_size % CPU_HEAP_ALIGMENT;
> expected += mod;
>
> Adding a helper function in the test to compute the expected
> size allocated and validate the return may be wise if multiple
> size allocations are going to be tested.
>
>
> > > formatter for rtems source files.  Can someone tell me how to use it
> and if
> > > it is on the main branch?
> >
> > This was part of a gsoc project last year. We haven't quite made the
> > switch over to it and the associated coding style I think, but you can
> > find the code via
> > https://devel.rtems.org/wiki/GSoC/2021#StudentsSummerofCodeTrackingTable
> > the student was Meh Mbeh Ida Delphine
> >
> >
> > > _______________________________________________
> > > 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

Reply via email to