Re: malloca, freea are not thread-safe

2018-01-10 Thread Bruno Haible
Florian Weimer wrote: > freea also causes valgrind warnings because it contains an out-of-bounds > access. This is very undesirable because it will cause programmers to > miss real bugs. As a mitigation, the 'malloca' module contains a file, malloca.valgrind, that tells valgrind to ignore

Re: malloca, freea are not thread-safe

2018-01-10 Thread Bruno Haible
Ondřej Bílka wrote: > This could be done faster without hash table by making alloca result > aligned to 2 * S and malloc ones not aligned to 2 * S by adding some padding. Nice trick. This can be done without violating the rules of how alloca() is used. A similar idea, that also consists in

Re: malloca, freea are not thread-safe

2018-01-10 Thread Ondřej Bílka
On Wed, Jan 10, 2018 at 03:02:17PM +0100, Florian Weimer wrote: > The mmalloca function used to implement malloca accesses a static > global array without synchronization: > > #define HASH_TABLE_SIZE 257 > static void * mmalloca_results[HASH_TABLE_SIZE]; > … > mmalloca (size_t n) > { > … > /*

malloca, freea are not thread-safe

2018-01-10 Thread Florian Weimer
The mmalloca function used to implement malloca accesses a static global array without synchronization: #define HASH_TABLE_SIZE 257 static void * mmalloca_results[HASH_TABLE_SIZE]; … mmalloca (size_t n) { … /* Enter p into the hash table. */ slot = (uintptr_t) p %