pkg: TLSF does not build for 16 bit platforms

[OlegHahm]

/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:73:1: error: size of array 'static_assert73' is negative
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:74:1: error: size of array 'static_assert74' is negative
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:78:1: error: size of array 'static_assert78' is negative
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:136:1: error: left shift count >= width of type [-Werror]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:136:38: error: initializer element is not a constant expression [-Werror]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c: In function 'offset_to_block'
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:222:9: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:222:9: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c: In function 'align_ptr'
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:278:4: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:280:9: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c: In function 'tlsf_add_pool'
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:602:7: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c: In function 'tlsf_create'
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:643:7: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c: In function 'tlsf_memalign'
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:695:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:695:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:703:31: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:703:31: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:707:10: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
/home/oleg/git/miniature-dangerzone/ccnlriot/bin/z1/tlsf-src/tlsf.c:707:10: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
cc1: all warnings being treated as errors

[miri64]

I have a dim memory that this was a constraint of TLSF to achieve O(1) runtime.

[haukepetersen]

wont be fixed for this release -> postponed.

[kYc0o]

Is this issue still present?

[OlegHahm]

AFAIR this is an inherent problem of the TLSF implementation. One way to go around it, would be just not to offer TLSF support for 16-bit platforms and add another package for malloc on these platforms.

[kYc0o]

Ok well let's discuss it for the next release.

[miri64]

I say the same, since it is an inherent problem I don't see it necessary to mark it as a "known issue"

[Umleitungen]

hello,
is this fixed? I got the same issue at the release 2016.10, when I try to build ccn-lite-replay example to z1 board.

[OlegHahm]

No, it's not fixed - and probably won't be fixed. For 16 bit platforms you have to use an alternative malloc() implementation.

[kYc0o]

No, it's not fixed - and probably won't be fixed

#9006 didn't help on this is it? I guess it wasn't tested for 16bit platforms but I'd like to know if there's a connection.

[miri64]

Since the pkg's doc clearly states, that it only work for 32-bit platforms, this issue is a classic example for a wontfix ;-). However, I agree with @OlegHahm on

For 16 bit platforms you have to use an alternative malloc() implementation.

@jcarrano didn't you find something like this?

[jcarrano]

@OlegHahm @miri64 Take a look at UMM malloc. It seems quite nice, it's workings are documented and it has very low overhead. Also, unlike TLSF, it has no tunable parameters.

It uses double linked lists, with 16bit offsets instead of pointers, because you will never be managing so much memory in a MCU. I thinks it's simplicity and low overhead could mean that we could use it to replace all usages of custom allocators (so we will still have #9434 -style bugs, but only once)

Downsides: It is not O(1), but I don't think there's such a huge need for O(1), arbitrarily-sized block allocators (correct me if I'm wrong). Also, it would need some modifications in order to work with user-supplied arrays (looking at the code, it seems totally doable).

On my part, I could use it for my Lua work but to make sure time is well spent I won't do anything unless there's interest from more people.

[kaspar030]

Downsides: It is not O(1), but I don't think there's such a huge need for O(1), arbitrarily-sized block allocators (correct me if I'm wrong).

O(1) means it is suitable for realtime code.
tlsf has some other desirable properties, e.g., a paper describing it's fragmentation behaviour.

If those are not needed, what's wrong with newlib's malloc()?

[jcarrano]

O(1) means it is suitable for realtime code.

If the rest of the code is not O(1), then it does not matter. If the allocator is O(n) and n is known beforehand and the worst case fits into the time available, it does not matter either.

If those are not needed, what's wrong with newlib's malloc()?

I'm using TLSF because you can provide an array and do allocations there. malloc() uses a system-wide pool.

• A leak will last until the device is reset.
• One subsystem can exhaust memory, leading to failure in another subsystem.
• As already mentioned in newlib: add thread safe implementation #8619, there may be some issues with multiple threads calling malloc().

For my particular use case (Lua), I wanted to isolate the interpreter from the rest of the system as much as possible.

[OlegHahm]

How about closing this issue and open another one as a feature request for a O(1) memory allocator that supports platforms < 32 bit?

[miri64]

👍

[jcarrano]

@OlegHahm I agree. Also, in my opinion, a O(n) allocator that works on user-supplied chunks of memory can be useful too.

[OlegHahm]

Totally agreed. I think in the best case we provide multiple pool-based memory allocators.

[jcarrano]

How about closing this issue and open another one as a feature request for a O(1) memory allocator that supports platforms < 32 bit?

Agreed. Closing this - if anyone ever finds the need for a O(1) allocator supporting <32 bits, feel free to open an issue (or better a PR).