Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4216
Return-Path: <sascha@schumann.cx>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 16360 invoked by uid 1010); 28 Aug 2003 04:30:50 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 15615 invoked from network); 28 Aug 2003 04:30:23 -0000
Received: from unknown (HELO milton.schell.de) (217.160.72.35)
  by pb1.pair.com with SMTP; 28 Aug 2003 04:30:23 -0000
Received: (qmail 8794 invoked by uid 501); 28 Aug 2003 04:30:09 -0000
Received: from unknown (HELO eco.foo) (80.143.19.180)
  by kdserv.de with SMTP; 28 Aug 2003 04:30:09 -0000
Received: from localhost (localhost [127.0.0.1])
	by eco.foo (Postfix) with ESMTP
	id 335DD384C7; Thu, 28 Aug 2003 06:30:09 +0200 (CEST)
Date: Thu, 28 Aug 2003 06:30:09 +0200 (CEST)
X-X-Sender: sas@eco.foo
To: Ard Biesheuvel <abies@php.net>
Cc: internals@lists.php.net
In-Reply-To: <20030827204254.35421.qmail@pb1.pair.com>
Message-ID: <Pine.LNX.4.56.0308280608060.30442@eco.foo>
References: <20030827204254.35421.qmail@pb1.pair.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] [PATCH] __attribute_malloc__ for malloc-like functions
From: sascha@schumann.cx (Sascha Schumann)

> 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
> cases, the pointers are expected not to be zero, and are being
> dereferenced in the code that immediately follows it [without checking
> for validity first].

    Segfaulting early is a good thing.  Whenever a crash occurs a
    defect has been found and needs to be fixed.  If the NULL would
    just be silently ignored, the real bug (where NULL is
    erroneously inserted) could slip by and make it into a
    release.

> Wouldn't it be more straight-forward to introduce an analogue for
> zend_hash_find() (eg. 'void *zend_hash_get()') which returns the stored
> pointer [or NULL on failure]. It could be used for applications where
> null pointers aren't allowed, and fix current code, where the implicit
> assumption is made the SUCCESS means the the pointers is non-null.

    Then you would also need a _set function which rejects NULL
    values.  Considering that the existing APIs have worked quite
    well in the past, I don't see a need for adding such a class
    of APIs.

> Last of all, I would like to know if we care about the warnings.
> Personally I don't really mind, as GCC's capabilities of accurately
> identifying violations of strict-aliasing rules are limited anyway.

    I think we should address them.  Many warnings provide
    information about potential defects, but the flood of aliasing
    warnings deters developers from considering the relevant
    ones.

    - Sascha