Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc

2002-10-09 Thread Jon Parise

A new CODING_STANDARDS patch is attached, based on feedback from Andi
and Dan (thanks!).  Please review and comment.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)


Index: CODING_STANDARDS
===
RCS file: /repository/php4/CODING_STANDARDS,v
retrieving revision 1.22
diff -u -r1.22 CODING_STANDARDS
--- CODING_STANDARDS9 Sep 2002 07:54:11 -   1.22
+++ CODING_STANDARDS9 Oct 2002 13:41:35 -
@@ -122,6 +122,20 @@
  existing.  End users should use function_exists() to test for the
  existence of a function
 
+[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library
+ counterparts.  These functions implement an internal safety-net
+ mechanism that ensures the deallocation of any unfreed memory at the
+ end of a request.  They also provide useful allocation and overflow
+ information while running in debug mode.
+
+ In almost all cases, memory returned to the engine must be allocated
+ using emalloc().
+
+ malloc() should only be used in instances where you need to allocate
+ memory that will be freed (via free()) inside of a third-party library.
+ It should also be used in instances where allocated memory has to
+ survive between multiple requests.
+
 Naming Conventions
 --
 



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc

2002-10-09 Thread Markus Fischer

On Wed, Oct 09, 2002 at 09:47:10AM -0400, Jon Parise wrote : 
 +[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library
 + counterparts.  These functions implement an internal safety-net
 + mechanism that ensures the deallocation of any unfreed memory at the
 + end of a request.  They also provide useful allocation and overflow
 + information while running in debug mode.
 +
 + In almost all cases, memory returned to the engine must be allocated
 + using emalloc().
 +
 + malloc() should only be used in instances where you need to allocate
 + memory that will be freed (via free()) inside of a third-party library.
 + It should also be used in instances where allocated memory has to
 + survive between multiple requests.
 +

+1

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc

2002-10-09 Thread DJ Anubis

Le Mercredi 9 Octobre 2002 16:01, Markus Fischer a écrit :
 On Wed, Oct 09, 2002 at 09:47:10AM -0400, Jon Parise wrote :
  +[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C
  library + counterparts.  These functions implement an internal
  safety-net + mechanism that ensures the deallocation of any unfreed
  memory at the + end of a request.  They also provide useful
  allocation and overflow + information while running in debug mode.
  +
  + In almost all cases, memory returned to the engine must be
  allocated + using emalloc().
  +
  + malloc() should only be used in instances where you need to
  allocate + memory that will be freed (via free()) inside of a
  third-party library. + It should also be used in instances where
  allocated memory has to + survive between multiple requests.
  +

 +1
+1


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc

2002-10-09 Thread Andi Gutmans

Looks good!

Andi

At 09:47 AM 10/9/2002 -0400, Jon Parise wrote:
A new CODING_STANDARDS patch is attached, based on feedback from Andi
and Dan (thanks!).  Please review and comment.

--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] CODING_STANDARDS addition re: emalloc

2002-10-08 Thread Jon Parise

Attached is a patch that adds a new item to CODING_STANDARDS that
suggests using emalloc() and friends over the standard C library
version.  It also offers an explanation, courtesy of Rasmus' reply to
my earlier question on the subject.

If no one objects to the addition in principle or in wording, I'll
commit this in a few days.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)


Index: CODING_STANDARDS
===
RCS file: /repository/php4/CODING_STANDARDS,v
retrieving revision 1.22
diff -u -r1.22 CODING_STANDARDS
--- CODING_STANDARDS9 Sep 2002 07:54:11 -   1.22
+++ CODING_STANDARDS9 Oct 2002 02:09:46 -
@@ -122,6 +122,15 @@
  existing.  End users should use function_exists() to test for the
  existence of a function
 
+[11] Prefer emalloc(), efree(), estrdup(), etc. to their standard C library
+ counterparts.  These functions implement an internal safety-net
+ mechanism that ensures the deallocation of any unfreed memory at the
+ end of the request.  They also provide useful allocation and overflow
+ information when running in debug mode.
+
+ malloc() should only be used in instances where you need to allocate
+ memory that will be freed (via free()) inside of a third-party library.
+
 Naming Conventions
 --
 



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc

2002-10-08 Thread Andi Gutmans

It might be a good idea to mention that almost in all cases memory returned 
to the engine has to be emalloced.
You can also mention that malloc() also should be used if the memory has to 
survive in between requests.

Andi

At 10:14 PM 10/8/2002 -0400, Jon Parise wrote:
Attached is a patch that adds a new item to CODING_STANDARDS that
suggests using emalloc() and friends over the standard C library
version.  It also offers an explanation, courtesy of Rasmus' reply to
my earlier question on the subject.

If no one objects to the addition in principle or in wording, I'll
commit this in a few days.

--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php