Bug #63520 [Com]: JSON extension includes a problematic license statement

2013-08-30 Thread jsjoh...@php.net
Edit report at https://bugs.php.net/bug.php?id=63520&edit=1

 ID: 63520
 Comment by: jsjoh...@php.net
 Reported by:kaplan at debian dot org
 Summary:JSON extension includes a problematic license
 statement
 Status: Assigned
 Type:   Bug
 Package:JSON related
 PHP Version:Irrelevant
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

When the decision is made, can we get a public statement on the site about it? 
Posts like the one on iteration99 (dot) com are only raising the confusion 
level 
among devs when really this isn't something directly impacting most PHP 
developers.


Previous Comments:

[2013-08-29 01:04:59] v3qqd2w4 dot ov0 at 20minutemail dot com

I hate to add to the noise, but has anyone pointed out to JSON that leaving it 
to a court to interpret "shall be used for Good, not Evil" is a highly 
unpredictable outcome? The entire license could be invalidated -- since it has 
no severability clause -- meaning nobody except the copyright owner is allowed 
to use any of the JSON code for anything. Is that really a potential outcome 
that they want?


[2013-08-28 10:26:30] d...@php.net

I'd be more than happy to see a json extension drop-in. Obviously we cannot 
change the license without the authors permissions, so a drop-in would be the 
best approach.


[2013-08-28 09:20:59] paj...@php.net

Besides the license issue, which is a problem but not a php one, Remi's new 
extension brings its lot of nice new stuff.

Please leave this open and add a link to the new extension and RFC, to avoid 
endless confusion here.


[2013-08-28 08:02:41] r...@php.net

This issue need to be discussed by all PHP developers.

I plan to submit a RFC in a few days.
This bug will be closed according to the vote result.


[2013-08-28 07:51:20] r...@php.net

Keep this open.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=63520


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63520&edit=1


Bug #47675 [Com]: File descriptor leaked due to HAVE_BROKEN_GETCWD

2011-09-27 Thread jsjoh...@php.net
Edit report at https://bugs.php.net/bug.php?id=47675&edit=1

 ID: 47675
 Comment by: jsjoh...@php.net
 Reported by:cs at ecn dot purdue dot edu
 Summary:File descriptor leaked due to HAVE_BROKEN_GETCWD
 Status: No Feedback
 Type:   Bug
 Package:Apache2 related
 Operating System:   Solaris 10
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

I've heard that this was fixed in PHP 5.3.5. It's not listed in the release 
notes 
from what I can see, so can someone confirm if 5.3.5 addresses this issue?


Previous Comments:

[2011-05-18 18:23:29] pyorke at joyent dot com

This still broken in PHP 5.3.3

When is it going to be fixed


[2010-08-08 10:20:55] php at marino dot st

I've been trying to track down this file descriptor leakage problem for months. 
 I was stuck on 5.2.8 because of it.  I confirm that the issue is specifically 
with Solaris 10.  I have opensolaris sxce nevada 130 locally and I've not seen 
FD leakage on it.

I confirm that patch suggested by bryan at stansell dot org seemed to correct 
the problem.  FYI, PHP was spawned and remains persistent for use with the 
Litespeed web server (uses the LSAPI interface), so it would run out of file 
descriptors between 1 and 12 hours on my site.  It's a bit disappointing that 
this error has been present for 5 releases and was never fixed.


[2010-01-12 15:40:45] bryan at stansell dot org

I finally got a chance to test a theory.  Looks like the volatile attribute 
fixed things for me.

#if HAVE_BROKEN_GETCWD
volatile int old_cwd_fd = -1;
#else

Once I added that, the setjmp/longjmp worked as expected.  I got the idea from 
the manpage on Solaris:

 The values of register and  automatic  variables  are  unde-
 fined.  Register  or automatic variables whose value must be
 relied upon must be declared as volatile.

Perhaps it's a gcc/gas/Solaris/x86 optimization somewhere that overlooked the 
case, but this is a workaround.  Of course, undefining HAVE_BROKEN_GETCWD for 
Solaris also works, if you have a web tree that isn't restricted in some way.


[2010-01-09 06:59:22] bryan at stansell dot org

I've encountered this problem using OpenSolaris (snv_115), apache 1.3.41 and 
php-5.2.12 (via mod_php5).  It was also a problem with php 5.2.9.  My apache 
processes continue to accumulate open files pointing to the directory which 
contains the php script.

I am using gcc 4.3.3, gnu as, and solaris ld.  It makes me wonder if it's a 
compiler-related thing.

I was also talking to a friend and we checked his httpd processes and saw the 
same file descriptor leak.  His setup is Solaris 9 (sparc), apache 1.3.41, php 
4.4.8, and gcc 4.0.2.

I worked around my problem by unsetting HAVE_BROKEN_GETCWD.  I have a couple 
other ideas on possibly narrowing down the problem, but I haven't had a chance 
to try them.


[2009-06-29 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=47675


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=47675&edit=1