What were you saying about non-portable compiler tricks the other day?
10:15am riddler:~/php43> make
/bin/sh /home/rasmus/php43/libtool --silent --preserve-dup-deps --mode=compile gcc
-Iext/zlib/ -I/home/rasmus/php43/ext/zlib/
-DPHP_ATOM_INC -I/home/rasmus/php43/include -I/home/rasmus/php43/main
account that every pointer in scope might be an alias of the resulting
value. __attribute_malloc__ fixes that. (Disabled for non-GCC compilers)
What about erealloc? It can return the same pointer as
passed to it.
GNU C realloc() does have the __attribute__((malloc)) itself. This seems
r
I've also added a few other attributes in a couple of places.
What do you think about the nonnull attribute?
I do think the attributes ((pure)) and ((const)) could make a
difference. (For instance, hashing functions or any other function that
base their result solely on their arguments)
> A check for 2.96 has been committed a while ago. What do you
> think about adding the malloc attribute to functions which
> either return NULL or an emalloc'ed pointer?
If the return type is char* or void*, adding the malloc attribute would
be appropriate. Aliasing isn't an issue fo
> So if you include any system library, GCC will silently ignore the
> __attribute_malloc__, which is why it worked for me when I tested
> compiling anything from the PHP tree with gcc-2.95.
Unfortunately, that is a Linux feature. E.g. FreeBSD 4 has a
sys/cdefs.h, but does not define anyt
>
> Nope, it does not.
>
You are right. Taken from :
#if __GNUC_PREREQ (2,96)
# define __attribute_malloc__ __attribute__ ((__malloc__))
#else
# define __attribute_malloc__ /* Ignore */
#endif
So if you include any system library, GCC will silently ignore the
__attribute_malloc__, which is wh
>
> Nope, it does not.
>
You are right. Taken from :
#if __GNUC_PREREQ (2,96)
# define __attribute_malloc__ __attribute__ ((__malloc__))
#else
# define __attribute_malloc__ /* Ignore */
#endif
So if you include any system library, GCC will silently ignore the
__attribute_malloc__, which is wh
On Thu, 28 Aug 2003, Ard Biesheuvel wrote:
> > attribute((malloc)) is now enabled in CVS. Note that
> > erealloc was excluded.
>
> I used __attribute_malloc__ intentionally, because it is also supported
> by GCC 2.
A helpful comment from ansidecl.h:
Attribute __malloc__ on f
On Thu, 28 Aug 2003, Ard Biesheuvel wrote:
> > attribute((malloc)) is now enabled in CVS. Note that
> > erealloc was excluded.
>
> I used __attribute_malloc__ intentionally, because it is also supported
> by GCC 2.
Nope, it does not.
$ cat m.c
void *p(void) __attribute_malloc__;
$ g
attribute((malloc)) is now enabled in CVS. Note that
erealloc was excluded.
I used __attribute_malloc__ intentionally, because it is also supported
by GCC 2.
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> I expect the effect to be significant, though, because (as I pointed
> out) the void* return-type of [e]malloc() causes it to alias with every
> pointer variable in scope, which severely limits the applicability of
> certain GCC optimizations.
attribute((malloc)) is now enabled in CVS. Note
> account that every pointer in scope might be an alias of the resulting
> value. __attribute_malloc__ fixes that. (Disabled for non-GCC compilers)
What about erealloc? It can return the same pointer as
passed to it.
> After looking through some of the code, I found out that in a lot of
I'd just make gcc shut up about it. Using void ** is the generic way to
do what we want to do and I see no reason to introduce another way that
works only in a subset of the cases, and will require tons of code
changes. I have to admit I still haven't been able to figure out what
gcc thinks i
At 23:43 27/08/2003, Ard Biesheuvel wrote:
The other thing is, that a lot of warnings are being triggered by
invocations of zend_hash_find(). This function stores its result in the
location pointed to by a void** argument, and returns an int specifying
whether the key was found or not. As the co
Hello group,
After having spent some time digging into the origin of the
strict-aliasing warnings when compiling with GCC 3.3 (brought about by
Stefan Roehrich's post a couple of days ago), I came up with a couple of
things that might be of interest in the development of PHP.
First of all, GCC
15 matches
Mail list logo
