Re: [PATCH] c99 math func log2
On Sun, 2008-01-06 at 01:45 -0500, Mike Frysinger wrote: On Wednesday 31 October 2007, Natanael Copa wrote: Here is a patch for the c99 math func log2(). If this gets applied I will look into the other c99 math funcs as well. is this function actually needed by something ? the current working policy has been to merge C99 functions really only on demand ... -mike No, its not needed by anything afaik. I dropped adding math funcs since it seems like the missing are (almost) never used. -nc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Sun, Jan 06, 2008 at 01:35:53AM -0500, Mike Frysinger wrote: On Wednesday 19 December 2007, Daniel Jacobowitz wrote: --- libc/inet/resolv.c (revision 189757) +++ libc/inet/resolv.c (local) @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( char *cp, **alias; int aliases, i, ret = HOST_NOT_FOUND; + /* Align to at least the size of a char * so we can put + pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + considering buflen gets checked constantly before being utilized, i dont think we need an additional check to see if it could possibly store a pointer. we just need to make sure the adjustment alone doesnt cause size_t underflow. That's exactly what I just did, except for the spelling of the alignment; sizeof(size_t) is sufficient on all Linux platforms for everything that gethostbyname_r puts in the buffer. i think this should be sufficient: /* Make sure the incoming char * buffer is aligned enough to * handle our random structures. This define is the same as we * use for malloc alignment (which has same requirements). */ i = (size_t)buf __alignof__(double __attribute_aligned__ (sizeof(size_t))); if (buflen i) return ERANGE; buf += i; buflen += i; - Why sizeof(size_t)? What does that have to do with anything, if you're already using __alignof__? - (size_t) buf 8 is not what you're trying to calculate, you need a -1. - buflen -= i, not plus -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: It seems, GCC 3.4.6 preprocessor supports ## concatenations incorrectly. I've took ENTRY definition from the sysdeps.h of the ia64/sysdeps.h It works. name##: is incorrect. ## is supposed to be used between parts of a single pp-token; : is a token all by itself. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
Will Newton wrote: Hi Bernd, (I hope I got the right email address here) I noticed commit 20613 prepends an underscore to the symbol name passed to dlsym() if __UCLIBC_NO_UNDERSCORE__ is not defined. I was wondering if you could explain the rationale behind this change? It seems to me the it's just the opposite +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC (rev 20613) @@ -175,4 +175,10 @@ # define DL_MALLOC_ALIGN (__WORDSIZE / 8) #endif +#ifdef __UCLIBC_NO_UNDERSCORES__ +#define __C_SYMBOL_PREFIX__ +#else +#define __C_SYMBOL_PREFIX__ _ +#endif + #endif /* _LD_DEFS_H */ or not? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
On Monday 07 January 2008, Daniel Jacobowitz wrote: On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: It seems, GCC 3.4.6 preprocessor supports ## concatenations incorrectly. I've took ENTRY definition from the sysdeps.h of the ia64/sysdeps.h It works. name##: is incorrect. ## is supposed to be used between parts of a single pp-token; : is a token all by itself. shouldnt gcc be uniformly barfing on this instead of sporadically ? should i open a gcc PR about gcc wrongly accepting name##: ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Monday 07 January 2008, Daniel Jacobowitz wrote: On Sun, Jan 06, 2008 at 01:35:53AM -0500, Mike Frysinger wrote: On Wednesday 19 December 2007, Daniel Jacobowitz wrote: --- libc/inet/resolv.c (revision 189757) +++ libc/inet/resolv.c (local) @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( char *cp, **alias; int aliases, i, ret = HOST_NOT_FOUND; + /* Align to at least the size of a char * so we can put + pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; considering buflen gets checked constantly before being utilized, i dont think we need an additional check to see if it could possibly store a pointer. we just need to make sure the adjustment alone doesnt cause size_t underflow. That's exactly what I just did, except for the spelling of the alignment; sizeof(size_t) is sufficient on all Linux platforms for everything that gethostbyname_r puts in the buffer. i misunderstood the purpose of the second assignment. i'll put together a test case and commit a fix ... i think this should be sufficient: /* Make sure the incoming char * buffer is aligned enough to * handle our random structures. This define is the same as we * use for malloc alignment (which has same requirements). */ i = (size_t)buf __alignof__(double __attribute_aligned__ (sizeof(size_t))); if (buflen i) return ERANGE; buf += i; buflen += i; - Why sizeof(size_t)? What does that have to do with anything, if you're already using __alignof__? this is taken from the existing malloc code which takes into account different arch quirks for alignment - (size_t) buf 8 is not what you're trying to calculate, you need a -1. ah right, i thought you were after something else with the second line - buflen -= i, not plus i pointed this typo out already ... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Mon, Jan 07, 2008 at 11:39:39AM -0500, Mike Frysinger wrote: i misunderstood the purpose of the second assignment. i'll put together a test case and commit a fix ... Thank you! - buflen -= i, not plus i pointed this typo out already ... Sorry, stray list filters. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
On Monday 07 January 2008, Daniel Jacobowitz wrote: On Mon, Jan 07, 2008 at 11:36:01AM -0500, Mike Frysinger wrote: On Monday 07 January 2008, Daniel Jacobowitz wrote: On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: It seems, GCC 3.4.6 preprocessor supports ## concatenations incorrectly. I've took ENTRY definition from the sysdeps.h of the ia64/sysdeps.h It works. name##: is incorrect. ## is supposed to be used between parts of a single pp-token; : is a token all by itself. shouldnt gcc be uniformly barfing on this instead of sporadically ? should i open a gcc PR about gcc wrongly accepting name##: ? The current versions of GCC do exactly what the standard say they ought to: gq.c:2:1: error: pasting name and : does not give a valid preprocessing token what are you defining as current ? the current release (4.2.2) certainly accepts it as does a large majority of compiler versions (going by the fact that this is the first such bug report after using this code for quite a while): $ cat test.S #define foo(name) name##: foo(f) $ gcc -c test.S $ gcc --version gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
On Mon, Jan 07, 2008 at 12:00:20PM -0500, Mike Frysinger wrote: The current versions of GCC do exactly what the standard say they ought to: gq.c:2:1: error: pasting name and : does not give a valid preprocessing token what are you defining as current ? the current release (4.2.2) certainly accepts it as does a large majority of compiler versions (going by the fact that this is the first such bug report after using this code for quite a while): $ cat test.S #define foo(name) name##: foo(f) $ gcc -c test.S $ gcc --version gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0) Sorry, I forgot that it depends what language you're compiling. It's accepted for assembly, but not for C. There's special cases for # (stringify) too. I don't know why. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
what are you defining as current ? the current release (4.2.2) certainly accepts it as does a large majority of compiler versions (going by the fact that this is the first such bug report after using this code for quite a while): As you told, GCC 3.4.6 accepts name##: w/o -std=gnu99 $ cat test.S #define foo(name) name##: foo(f) $ mipsel-linux-uclibc-gcc -c test.S $ $mipsel-linux-uclibc-gcc -c -std=gnu99 test.S test.S:3:1: pasting f and : does not give a valid preprocessing token $ $mipsel-linux-uclibc-gcc --version mipsel-linux-uclibc-gcc (GCC) 3.4.6 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
