| Age | Commit message (Collapse) | Author |
|---|
|
(patch by Bernd Schmidt <bernds_cb1 at t-online.de>)
|
|
In file included from toolchain_build_i386/gcc-3.4.6/libiberty/hashtab.c:49:
build_i386/staging_dir/i386-linux-uclibc/sys-include/malloc.h:193: error: ISO C forbids data definition with no type or storage class
|
|
When no TIOCGPTN definition is present in the kernel headers, the library's ptsname() function will not work.
The libc/stdlib/ptsname_r.c file is the problem. This file includes a complicated nest of #if directives. One of these #if's has the opposite sense from what is required.
|
|
reduction is achieved by direct use of user-supplied PATH_MAX sized
buffer for result (without intermediate copy) and changes
in copy_buf[] usage - now it is used for both "source" pathname
and link name (it works because they have to be less than PATH_MAX combined,
otherwise we return NULL).
|
|
|
|
thus need to initialize stuff with 0 to force it into bss.
All hell can again break loose if future gcc will be smart enough
to ignore it.
|
|
|
|
|
|
|
|
|
|
|
|
trigger a buffer overflow in that case
|
|
|
|
|
|
Hi. I have found a bug in realpath that did not allow me to use it with
symlinks. Although I am using 0.9.28.1, the bug is present in 0.9.28 and
also in the trunk.
I attach a suggested patch. Please let me know if the solution is correct.
|
|
|
|
However, retesting on m68k showed up a problem that had appeared in
uClibc since the last time I tried. Specifically, revision 15785 did:
-#define HEAP_GRANULARITY (sizeof (HEAP_GRANULARITY_TYPE))
+#define HEAP_GRANULARITY (__alignof__ (HEAP_GRANULARITY_TYPE))
-#define MALLOC_ALIGNMENT (sizeof (double))
+#define MALLOC_ALIGNMENT (__alignof__ (double))
The problem is that
(a) MALLOC_HEADER_SIZE == MALLOC_ALIGNMENT
(b) the header contains a size value of type size_t
(c) sizeof (size_t) is 4 on m68k, but...
(d) __alignof__ (double) is only 2 (the largest alignment used on m68k)
So we only allocate 2 bytes for the 4-byte header, and the least
significant 2 bytes of the size are in the user's area rather than
the header. The patch below fixes that problem by redefining
MALLOC_HEADER_SIZE to:
MAX (MALLOC_ALIGNMENT, sizeof (size_t))
(but without the help of the MAX macro ;)). However, we really would
like to have word alignment on Coldfire. It makes a big performance
difference, and because we have to allocate a 4-byte header anyway,
what wastage there is will be confined to the end of the allocated block.
Any wastage will also be limited to 2 bytes per allocation compared to
the current alignment.
I've therefore used the __aligned__ type attribute to create a double
type that has at least sizeof (size_t) bytes of alignment. I've
introduced a new __attribute_aligned__ macro for this. It might seem
silly protecting against old or non-GNU compilers here, but the extra
alignment is only an optimisation, and having the macro is more in the
spirit of the other attribute code.
|
|
|
|
|
|
does not easily lend itself to becoming complete pthread cancelation
safe without first investing in some deep and serious thought...
The other malloc implementations are pthread cancelation safe, and
this one is mostly used for uClinux, where the lack is at least less
likely to be a common problem.
|
|
things, and avoid potential deadlocks caused when a thread holding a uClibc
internal lock get canceled and terminates without releasing the lock. This
change also provides a single place, bits/uClibc_mutex.h, for thread libraries
to modify to change all instances of internal locking.
|
|
things, and avoid potential deadlocks caused when a thread holding a uClibc
internal lock get canceled and terminates without releasing the lock. This
change also provides a single place, bits/uClibc_mutex.h, for thread libraries
to modify to change all instances of internal locking.
|
|
furthermore ifdef'ed out anyway.
|
|
Also make compilation conditional on float support.
|
|
|
|
bernds writes: Use __alignof__ instead of sizeof to get alignments. Eliminates some warnings about misalignments when malloc debugging is enabled.
|
|
I had clearly run search/replace on that were cluttering things up.
|
|
I had clearly run search/replace on that were cluttering things up.
|
|
|
|
|
|
_ISOC99/XOPEN_SOURCE
|
|
regardless of the setting of MALLOC_GLIBC_COMPAT.
|
|
most of global data relocations are back
|
|
|
|
prototypes. Should I do all the other *max aliases as well
|
|
|
|
|
|
|
|
|
|
linuxthreads[_db] as well, don't try on slow box
|
|
|
|
for .init and .fini array processing
for the gory details, see the mailing list:
http://www.uclibc.org/lists/uclibc/2006-January/014079.html
http://www.uclibc.org/lists/uclibc/2006-February/014285.html
|
|
libc.a/libc.so, the diffs go into libc-static-y/libc-shared-y exclusively, add IMA to libc, don't use any MSRC anymore
|
|
|
|
affected files
|
|
|
|
|
|
|
|
|
|
|
