#33153 [NEW]: segfaults when calling mssql_next_result

2005-05-26 Thread erudd at netfor dot com
From: erudd at netfor dot com
Operating system: Fedora Core 3 x86_64
PHP version:  4.3.11
PHP Bug Type: MSSQL related
Bug description:  segfaults when calling mssql_next_result

Description:

Using the mssql extension from PHP 4.3.11 on an x86_64 system. (core PHP
is latest FC3 RPMS, php-mssql is custom compiled RPM using freetds 0.63). 
Everything works fine except for calling the mssql_next_result function
(via PEAR::DB 1.7.6) apache and the command line client will segfault. 
This works fine on a MDK 10.1 32bit system w/ PHP 4.3.8. 

I havn't yet tried on a FC3 x86 system

Also the freetds commandline 'tsql" command runs the query without any
issues and returns all the result fields.

Reproduce code:
---
require_once("DB.php");
$db =& DB::connect("mssql://user:[EMAIL PROTECTED]/Database");
$sql = << 1
BEGIN
  FETCH NEXT FROM Search
  SET @limit = @limit -1
END
CLOSE Search
DEALLOCATE Search
EOSQL;
$res =& $db->query($sql);
$row =& $res->fetchRow(DB_FETCHMODE_ASSOC);
do {
  $return[] =& $row;
  $row =& $res->fetchRow(DB_FETCHMODE_ASSOC);
  if (is_null($row)) {
if ($res->nextResult()) {
   $row =& $res->fetchRow(DB_FETCHMODE_ASSOC);
}
  }
} while ($row);

Expected result:

Not to segfault and return 20 records from the table starting at record 5


-- 
Edit bug report at http://bugs.php.net/?id=33153&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33153&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33153&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33153&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33153&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33153&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33153&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33153&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33153&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33153&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33153&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33153&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33153&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33153&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33153&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33153&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33153&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33153&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33153&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33153&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33153&r=mysqlcfg


#33153 [NoF->Opn]: segfaults when calling mssql_next_result

2005-06-28 Thread erudd at netfor dot com
 ID:   33153
 User updated by:  erudd at netfor dot com
 Reported By:  erudd at netfor dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Fedora Core 3 x86_64
 PHP Version:  4.3.11
 New Comment:

I have tried the latest CVS code for the php-mssql extension and the
same results occur.. I updated to the lastest on the 0.63 branch of
freetds and apache/php no longer segfault, but PHP never advances to
the next result set.


Previous Comments:


[2005-06-03 01:00:04] 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".



[2005-05-30 10:31:51] freddyz77 at tin dot it

dblastrow should not fail, this is certainly a FreeTDS bug. Fixed in
CVS, expect a new 0.63.1 release.
However I don't understand why PHP calls dblastrow (related to dblib
buffering).

freddy77
(FreeTDS developer)



[2005-05-26 19:37:46] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





[2005-05-26 18:49:17] eddie at omegaware dot com

segfault occurs because of a null res_info in the dbproc that is passed
to the dblastrow function in freetds' dblib.

FreeTDS bug report on the issue

http://sourceforge.net/tracker/index.php?func=detail&aid=1209286&group_id=33106&atid=407806

Not sure if this is a freetds issue, or if php-mssql isn't doing
something correct.



[2005-05-26 18:23:22] eddie at omegaware dot com

Backtrace of the crash.

#0  dblastrow (dbproc=0x8c9530) at dblib.c:5909
#1  0x002a9a7f54bf in zif_mssql_next_result (ht=9213232,
return_value=0x7bde58, 
this_ptr=0x9034a0, return_value_used=9454256)
at
/home/erudd/RPMBUILD/BUILD/php-4.3.11/ext/mssql/php_mssql.c:1865
#2  0x0051c405 in execute (op_array=0x8004b8)
at /usr/src/debug/php-4.3.11/Zend/zend_execute.c:1654
#3  0x0051891b in execute (op_array=0x7f3128)
at /usr/src/debug/php-4.3.11/Zend/zend_execute.c:1698
#4  0x0051891b in execute (op_array=0x7af1b8)
at /usr/src/debug/php-4.3.11/Zend/zend_execute.c:1698
#5  0x0050869d in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/debug/php-4.3.11/Zend/zend.c:926
#6  0x004dc14a in php_execute_script
(primary_file=0x7fb550)
at /usr/src/debug/php-4.3.11/main/main.c:1745
#7  0x0052384a in main (argc=3, argv=0x7fb688)
at /usr/src/debug/php-4.3.11/sapi/cgi/cgi_main.c:1601



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
http://bugs.php.net/33153

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


#30962 [Com]: Space being returned for NULL columns

2005-02-15 Thread erudd at netfor dot com
 ID:   30962
 Comment by:   erudd at netfor dot com
 Reported By:  richard dot quadling at bandvulc dot co dot uk
 Status:   Open
 Bug Type: MSSQL related
 Operating System: Windows XP Pro SP2
 PHP Version:  5.0.3
 New Comment:

-- The reason I say this, is that if I make the column NULL, 
-- then I get NULL. If I make the column an empty string 
-- (i.e. select all and then delete - doing this in 
-- Enterprise Manager), I get a space in the result set! 

I recently came across this issue when upgrading to the lastest FreeTDS
and the lastet PHP 4.3.x connecting to MS SQL Server 2000. The issue was
actualy not php, as it was easily fixed by editing the freetds.conf and
set the global "tds version" from 4.2 to 7.0 and the space issue went
away.


Previous Comments:


[2005-01-12 21:15:26] public at nexia dot ca

I second the request by wchannospam at tomoye dot com to port this bug
fix to 4.3.x stream.

Its causing major issues for my PHP apps on Windows.



[2005-01-12 21:02:43] wchannospam at tomoye dot com

This problem is also appearing in PHP 4.3.x where x>=4. Can you
implement the same fix there as well. Thank you very much.



[2004-12-16 11:39:16] richard dot quadling at bandvulc dot co dot uk

Simple test script to show the problem.

' . var_export($row, True) . 'Length of ' .
$row['username'] . '\'s user_icq = ' . strlen($row['user_icq']) . '';
}
mssql_free_result($rResults);
mssql_close($rConn);
?>


Requires phpBB and at least 1 user defined with an ICQ number.
Obviously, you could choose any field or any other MS SQL database.

Richard.



[2004-12-16 11:32:42] richard dot quadling at bandvulc dot co dot uk

Back again in V5.0.3!

Or should that be still here?

I notice that the version of the code now tests to see if the length is
0 before the conversion of the data to its appropriate type.

Is it possible, that there is a distinction between NULL and 0?

My C knowledge says no. NULL is 0, but I may be wrong!

The reason I say this, is that if I make the column NULL, then I get
NULL. If I make the column an empty string (i.e. select all and then
delete - doing this in Enterprise Manager), I get a space in the result
set! Argh!

Is there ANY way a debug version could be built that reported that the
code that has been modified is actually called. I'd really like to know
what length IS being returned if the field is empty.

I am more than willing to help get this fixed, but I need some hand
holding in getting MSVC++ setup appropriately. I do not know what
additional tools I need. I am in the process of downloading Cygwin to
start some work on the PHP documentation (just getting the CHM compiled
first!).



[2004-12-03 03:27:19] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





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
http://bugs.php.net/30962

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


#45253 [NEW]: SimpleXML interface incosnsistent

2008-06-12 Thread erudd at netfor dot com
From: erudd at netfor dot com
Operating system: Linux
PHP version:  5.2.6
PHP Bug Type: SimpleXML related
Bug description:  SimpleXML interface incosnsistent

Description:

Referencing bug #44458

Where in the documentation does it state that the strings must be escaped
when setting attributes or assigning values to children. I can find it
nowhere in the documentation, nor any examples where you show that you
"must escape text content" before entering it into the attribute or text
content of an element.

Also this behavior is inconsistent behavior as when you fetch the data it
is NOT escaped. So why should I need to escape the data when putting it
in?

This makes simpleXML not so simple as I have to perform extra "unexpected"
work while storing data into the xml document.  Which I do not have to do
with the DOM extension.

Consistency should be high priority in this.. I should expect to retrieve
the same value out that I put in. the SimpleXML class should handle
encoding and decoding data for me so "I" don't have to think about it.

Reproduce code:
---
$sxml=new SimpleXMLElement('');
$sxml->addChild('child1','One & Two');
echo "Test 1:".(string)$sxml->child1."\n";

$sxml->addChild('child2','One & Two');
echo "Test 2:".(string)$sxml->child2."\n";

$sxml->addChild('child3');
$sxml->child3 = 'One & Two';
echo "Test 3:".(string)$sxml->child3."\n";


Expected result:

Test 1:One & Two
Test 2:One & Two
Test 3:One & Two

Actual result:
--
Test 1:One 
Test 2:One & Two
Test 3:One & Two


-- 
Edit bug report at http://bugs.php.net/?id=45253&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45253&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45253&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45253&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45253&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45253&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45253&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45253&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45253&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45253&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45253&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45253&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45253&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45253&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45253&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45253&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45253&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45253&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45253&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45253&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45253&r=mysqlcfg



#45253 [Opn]: SimpleXML interface incosnsistent

2008-06-12 Thread erudd at netfor dot com
 ID:   45253
 User updated by:  erudd at netfor dot com
 Reported By:  erudd at netfor dot com
 Status:   Open
 Bug Type: SimpleXML related
 Operating System: Linux
 PHP Version:  5.2.6
 New Comment:

The XMLWriter extension escapes my input for me as expected instead of
requiring me to escape the input first.


Previous Comments:


[2008-06-12 21:31:52] erudd at netfor dot com

Description:

Referencing bug #44458

Where in the documentation does it state that the strings must be
escaped when setting attributes or assigning values to children. I can
find it nowhere in the documentation, nor any examples where you show
that you "must escape text content" before entering it into the
attribute or text content of an element.

Also this behavior is inconsistent behavior as when you fetch the data
it is NOT escaped. So why should I need to escape the data when putting
it in?

This makes simpleXML not so simple as I have to perform extra
"unexpected" work while storing data into the xml document.  Which I do
not have to do with the DOM extension.

Consistency should be high priority in this.. I should expect to
retrieve the same value out that I put in. the SimpleXML class should
handle encoding and decoding data for me so "I" don't have to think
about it.

Reproduce code:
---
$sxml=new SimpleXMLElement('');
$sxml->addChild('child1','One & Two');
echo "Test 1:".(string)$sxml->child1."\n";

$sxml->addChild('child2','One & Two');
echo "Test 2:".(string)$sxml->child2."\n";

$sxml->addChild('child3');
$sxml->child3 = 'One & Two';
echo "Test 3:".(string)$sxml->child3."\n";


Expected result:

Test 1:One & Two
Test 2:One & Two
Test 3:One & Two

Actual result:
--
Test 1:One 
Test 2:One & Two
Test 3:One & Two






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



#45253 [Opn]: SimpleXML interface incosnsistent

2008-06-12 Thread erudd at netfor dot com
 ID:   45253
 User updated by:  erudd at netfor dot com
 Reported By:  erudd at netfor dot com
 Status:   Open
 Bug Type: SimpleXML related
 Operating System: Linux
 PHP Version:  5.2.6
 New Comment:

However when I do 
$xml->child = 'One & Two';

it does not work it results in 

echo (string)$xml->child;

printing "One ";

As I tried doing that to see if it was just the "function" being ODD or
the whole SimpleXML.

Basically this behavior has made simpleXML useless to me now.  I either
have to use the standard DOM interface, use XMLWriter (which I ended up
rewriting the code that had this issue to use XMLWriter instead).  OR
write my own wrapper class around simpleXML that does the same behavior
with respect to escaping that the rest of the XML APIs in PHP do.


Previous Comments:


[2008-06-13 00:50:48] maito dot gai at gmail dot com

You can have simplicity or completeness, but you can't have them both
at the same time. SimpleXML offers simplicity through its magic method
($sxml->child) and completeness through addChild().

If you don't want to bother with escaping, use
   $sxml->child1 = 'One & Two';

If you need to bypass escaping, use
   $sxml->addChild('child1', 'One & Two');

Without addChild(), or if addChild() was identical to the magic method,
it would be impossible to use XML entities, eg   would need to be
replaced by the actual character if the document's encoding. And if that
character was not available in that encoding (or charset, rather) then
it would simply be impossible to use.

That's why addChild()'s behaviour is both desirable and needed.

--------

[2008-06-12 21:46:33] erudd at netfor dot com

The XMLWriter extension escapes my input for me as expected instead of
requiring me to escape the input first.

--------

[2008-06-12 21:31:52] erudd at netfor dot com

Description:

Referencing bug #44458

Where in the documentation does it state that the strings must be
escaped when setting attributes or assigning values to children. I can
find it nowhere in the documentation, nor any examples where you show
that you "must escape text content" before entering it into the
attribute or text content of an element.

Also this behavior is inconsistent behavior as when you fetch the data
it is NOT escaped. So why should I need to escape the data when putting
it in?

This makes simpleXML not so simple as I have to perform extra
"unexpected" work while storing data into the xml document.  Which I do
not have to do with the DOM extension.

Consistency should be high priority in this.. I should expect to
retrieve the same value out that I put in. the SimpleXML class should
handle encoding and decoding data for me so "I" don't have to think
about it.

Reproduce code:
---
$sxml=new SimpleXMLElement('');
$sxml->addChild('child1','One & Two');
echo "Test 1:".(string)$sxml->child1."\n";

$sxml->addChild('child2','One & Two');
echo "Test 2:".(string)$sxml->child2."\n";

$sxml->addChild('child3');
$sxml->child3 = 'One & Two';
echo "Test 3:".(string)$sxml->child3."\n";


Expected result:

Test 1:One & Two
Test 2:One & Two
Test 3:One & Two

Actual result:
--
Test 1:One 
Test 2:One & Two
Test 3:One & Two






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



#45253 [Opn]: SimpleXML interface inconsistent

2008-06-13 Thread erudd at netfor dot com
 ID:   45253
 User updated by:  erudd at netfor dot com
 Reported By:  erudd at netfor dot com
 Status:   Open
 Bug Type: SimpleXML related
 Operating System: Linux
 PHP Version:  5.2.6
 New Comment:

Is addAttribute supposed to work the same way as addChild?? As
currently it does not (tested in 5.2.5 and 5.2.6)

Also

$xml = new SimpleXmlElement('');
$xml['attribute'] = "my val";

does not work it throws an error (5.2.6) claiming that the "objects
don't support array access operators".


Previous Comments:
----------------

[2008-06-13 19:50:34] erudd at netfor dot com

OK.. that code works fine on PHP 5.2.4, 5.2.5, and 5.2.6. However if
you don't predefine the element and update it's contents it was
expecting it to be "escaped".  Which is fixed on my fresh build of
5.2.6. (though wasn't clearly documented in the changelog (bug #44478))

(I have multiple version of PHP, that I'm unifying up to current).

Still,  this behavior is not documented in the documentation.

Should I file a new bug on the documentation to have it updated? or
just switch this one to "Add* methods for simpleXML need documentation
updated to show that input needs to be xml entity encoded"?



[2008-06-13 15:50:00] maito dot gai at gmail dot com

That's not SimpleXML's normal behaviour, and I couldn't reproduce it on
PHP 5.2.6-pl1-gentoo (cli) (built: May 26 2008 02:58:50) + libxml
2.6.31

Check out your PHP version and libxml version, perhaps you're
unknowingly running an older release.


Reproduce code:
---
$sxml=new SimpleXMLElement('');

$sxml->child1 = 'One & Two';
echo $sxml->child1, "\n";

$sxml->child1 = 'One & Two';
echo $sxml->child1, "\n";

Actual result:
--
One & Two
One & Two



[2008-06-13 01:40:27] erudd at netfor dot com

However when I do 
$xml->child = 'One & Two';

it does not work it results in 

echo (string)$xml->child;

printing "One ";

As I tried doing that to see if it was just the "function" being ODD or
the whole SimpleXML.

Basically this behavior has made simpleXML useless to me now.  I either
have to use the standard DOM interface, use XMLWriter (which I ended up
rewriting the code that had this issue to use XMLWriter instead).  OR
write my own wrapper class around simpleXML that does the same behavior
with respect to escaping that the rest of the XML APIs in PHP do.



[2008-06-13 00:50:48] maito dot gai at gmail dot com

You can have simplicity or completeness, but you can't have them both
at the same time. SimpleXML offers simplicity through its magic method
($sxml->child) and completeness through addChild().

If you don't want to bother with escaping, use
   $sxml->child1 = 'One & Two';

If you need to bypass escaping, use
   $sxml->addChild('child1', 'One & Two');

Without addChild(), or if addChild() was identical to the magic method,
it would be impossible to use XML entities, eg   would need to be
replaced by the actual character if the document's encoding. And if that
character was not available in that encoding (or charset, rather) then
it would simply be impossible to use.

That's why addChild()'s behaviour is both desirable and needed.



[2008-06-12 21:46:33] erudd at netfor dot com

The XMLWriter extension escapes my input for me as expected instead of
requiring me to escape the input first.



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
http://bugs.php.net/45253

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



#45253 [Opn]: SimpleXML interface inconsistent

2008-06-13 Thread erudd at netfor dot com
 ID:   45253
 User updated by:  erudd at netfor dot com
 Reported By:  erudd at netfor dot com
 Status:   Open
 Bug Type: SimpleXML related
 Operating System: Linux
 PHP Version:  5.2.6
 New Comment:

OK.. that code works fine on PHP 5.2.4, 5.2.5, and 5.2.6. However if
you don't predefine the element and update it's contents it was
expecting it to be "escaped".  Which is fixed on my fresh build of
5.2.6. (though wasn't clearly documented in the changelog (bug #44478))

(I have multiple version of PHP, that I'm unifying up to current).

Still,  this behavior is not documented in the documentation.

Should I file a new bug on the documentation to have it updated? or
just switch this one to "Add* methods for simpleXML need documentation
updated to show that input needs to be xml entity encoded"?


Previous Comments:


[2008-06-13 15:50:00] maito dot gai at gmail dot com

That's not SimpleXML's normal behaviour, and I couldn't reproduce it on
PHP 5.2.6-pl1-gentoo (cli) (built: May 26 2008 02:58:50) + libxml
2.6.31

Check out your PHP version and libxml version, perhaps you're
unknowingly running an older release.


Reproduce code:
---
$sxml=new SimpleXMLElement('');

$sxml->child1 = 'One & Two';
echo $sxml->child1, "\n";

$sxml->child1 = 'One & Two';
echo $sxml->child1, "\n";

Actual result:
----------
One & Two
One & Two



[2008-06-13 01:40:27] erudd at netfor dot com

However when I do 
$xml->child = 'One & Two';

it does not work it results in 

echo (string)$xml->child;

printing "One ";

As I tried doing that to see if it was just the "function" being ODD or
the whole SimpleXML.

Basically this behavior has made simpleXML useless to me now.  I either
have to use the standard DOM interface, use XMLWriter (which I ended up
rewriting the code that had this issue to use XMLWriter instead).  OR
write my own wrapper class around simpleXML that does the same behavior
with respect to escaping that the rest of the XML APIs in PHP do.



[2008-06-13 00:50:48] maito dot gai at gmail dot com

You can have simplicity or completeness, but you can't have them both
at the same time. SimpleXML offers simplicity through its magic method
($sxml->child) and completeness through addChild().

If you don't want to bother with escaping, use
   $sxml->child1 = 'One & Two';

If you need to bypass escaping, use
   $sxml->addChild('child1', 'One & Two');

Without addChild(), or if addChild() was identical to the magic method,
it would be impossible to use XML entities, eg   would need to be
replaced by the actual character if the document's encoding. And if that
character was not available in that encoding (or charset, rather) then
it would simply be impossible to use.

That's why addChild()'s behaviour is both desirable and needed.



[2008-06-12 21:46:33] erudd at netfor dot com

The XMLWriter extension escapes my input for me as expected instead of
requiring me to escape the input first.



[2008-06-12 21:31:52] erudd at netfor dot com

Description:

Referencing bug #44458

Where in the documentation does it state that the strings must be
escaped when setting attributes or assigning values to children. I can
find it nowhere in the documentation, nor any examples where you show
that you "must escape text content" before entering it into the
attribute or text content of an element.

Also this behavior is inconsistent behavior as when you fetch the data
it is NOT escaped. So why should I need to escape the data when putting
it in?

This makes simpleXML not so simple as I have to perform extra
"unexpected" work while storing data into the xml document.  Which I do
not have to do with the DOM extension.

Consistency should be high priority in this.. I should expect to
retrieve the same value out that I put in. the SimpleXML class should
handle encoding and decoding data for me so "I" don't have to think
about it.

Reproduce code:
---
$sxml=new SimpleXMLElement('');
$sxml->addChild('child1','One & Two');
echo "Test 1:".(string)$sxml->child1."\n";

$sxml->addChild('child2','One & Two');
echo "Test 2:".(string)$sxml->child2."\n";

$sxml->addChild('child3');
$sxml->child3 = 'One & Two';
echo "Test 3:".(string)$sxml->child3."\n";


Expected result:

Test 1:One & Two
Test 2:One & Two
Test 3:One & Two

Actual result:
--
Test 1:One 
Test 2:One & Two
Test 3:One & Two






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



#33153 [Asn]: segfaults when calling mssql_next_result

2005-10-17 Thread erudd at netfor dot com
 ID:   33153
 User updated by:  erudd at netfor dot com
 Reported By:  erudd at netfor dot com
 Status:   Assigned
 Bug Type: MSSQL related
 Operating System: FC3/FC4/MDK 10.2 x86 & x86_64
 PHP Version:  4.3.11
 Assigned To:  fmk
 New Comment:

Patch based on PHP_5_0 head branch
applies to php 5.0.4 and php 4.3.10.
tested and works with every I could throw at it (32 bit and 64 bit)

Index: php_mssql.c
===
RCS file: /repository/php-src/ext/mssql/php_mssql.c,v
retrieving revision 1.137.2.9
diff -u -r1.137.2.9 php_mssql.c
--- php_mssql.c 12 Apr 2005 17:46:06 -  1.137.2.9
+++ php_mssql.c 14 Oct 2005 23:02:42 -
@@ -1829,10 +1829,15 @@
WRONG_PARAM_COUNT;
}

ZEND_FETCH_RESOURCE(result, mssql_result *, mssql_result_index,
-1, "MS SQL-result", le_result);

mssql_ptr = result->mssql_ptr;
retvalue = dbresults(mssql_ptr->link);
+
+   while (dbnumcols(mssql_ptr->link) <= 0 && retvalue == SUCCEED)
{
+   retvalue = dbresults(mssql_ptr->link);
+   }
+
if (retvalue == FAIL) {
RETURN_FALSE;
}


Previous Comments:


[2005-08-09 16:17:35] freddyz77 at tin dot it

Problem here is that in mssql_next_result PHP do not ignore recordset
without columns

in mssql_query

/* Skip results not returning any columns */
while ((num_fields = dbnumcols(mssql_ptr->link)) <= 0 && retvalue ==
SUCCEED) { 
  retvalue = dbresults(mssql_ptr->link);
}

in mssql_execute

/* Skip results not returning any columns */
while ((num_fields = dbnumcols(mssql_ptr->link)) <= 0 && retval_results
== SUCCEED) {
  retval_results = dbresults(mssql_ptr->link);
}

but there is no such loop in mssql_next_result

freddy77

----------------

[2005-08-03 18:56:54] erudd at netfor dot com

Any updates on this issue? 

(Mandrake Bug #)
http://qa.mandriva.com/show_bug.cgi?id=17272

----------------

[2005-06-28 18:54:00] erudd at netfor dot com

I have tried the latest CVS code for the php-mssql extension and the
same results occur.. I updated to the lastest on the 0.63 branch of
freetds and apache/php no longer segfault, but PHP never advances to
the next result set.



[2005-05-30 10:31:51] freddyz77 at tin dot it

dblastrow should not fail, this is certainly a FreeTDS bug. Fixed in
CVS, expect a new 0.63.1 release.
However I don't understand why PHP calls dblastrow (related to dblib
buffering).

freddy77
(FreeTDS developer)



[2005-05-26 19:37:46] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





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
http://bugs.php.net/33153

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


#41539 [Com]: MSSQL ext. with freetds treats '' (string of length 0) as NULL in VARCHAR(MAX)

2007-06-18 Thread erudd at netfor dot com
 ID:   41539
 Comment by:   erudd at netfor dot com
 Reported By:  frode at coretrek dot com
 Status:   Assigned
 Bug Type: MSSQL related
 Operating System: Linux and win32
 PHP Version:  5.2.3
 Assigned To:  fmk
 New Comment:

Patch Developed w/ freetds maintainer to fix this issue

--- mssql/php_mssql.c.orig  2006-04-04 14:49:12.0 -0400
+++ mssql/php_mssql.c   2006-10-24 16:41:18.0 -0400
@@ -818,7 +818,7 @@
 
 static void php_mssql_get_column_content_with_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type  TSRMLS_DC)
 {
-   if (dbdatlen(mssql_ptr->link,offset) == 0) {
+   if (dbdatlen(mssql_ptr->link,offset) == 0 &&
dbdata(mssql_ptr->link,offset) == NULL) {
ZVAL_NULL(result);
return;
}
@@ -941,7 +941,7 @@
 
 static void php_mssql_get_column_content_without_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type TSRMLS_DC)
 {
-   if (dbdatlen(mssql_ptr->link,offset) == 0) {
+   if (dbdatlen(mssql_ptr->link,offset) == 0 &&
dbdata(mssql_ptr->link,offset) == NULL) {
ZVAL_NULL(result);
return;
}


Previous Comments:


[2007-06-04 14:16:12] frode at coretrek dot com

So I had a go at hacking on the C source for the mssql extension, and I
think I have come up with some sort of solution.

First of all, it appears that the regular FreeTDS dblib api has no way
to distinguish "" from NULL for varchar(max). dbdatlen() returns 0
either way, and dbdata() returns a pointer to 0x0. 

Looking at the source code for the FreeTDS tsql application, it became
obvious that when result set columns contains a real NULL, the
"column_cur_size" is always less than 0. Relevant piece of code from
tsql.c:

  if (col->column_cur_size < 0) {
if (print_rows)
  fprintf(stdout, "NULL\t");
continue;
  }

Unfortunately, negative column_cur_size is masked in dblib. Relevant
piece of code from
dblib.c's implementation of dbdatlen():

  if (colinfo->column_cur_size < 0)
ret = 0;
  else
ret = colinfo->column_cur_size;

So it seems we need to access the low level TDS structures to tell the
difference. 
Playing around with gdb, it seems that column_cur_size is 0 for strings
and -1 for real NULLs.

So I came up with an ugly hack for php_mssql.c. It does produce the
expected output,
but it's been a long time since I did anything serious in C, so I don't
know if it is 
the correct way of doing things. 

Tested on Windows 2003 x86, compiled with Microsoft Visual C++ 2005
(Compiler version 
14.00.50727.42 for 80x86), FreeTDS 0.64, running against an instance of
SQL Server 2005,
and c:\freetds.conf contains:
[global]
  tds version = 7.0
  
  
I also added a "dbdata(..) == NULL" condition to the if()
in php_mssql_get_column_content_without_type(), just because that
function seems to be similar to
what was fixed in
http://cvs.php.net/viewcvs.cgi/php-src/ext/mssql/php_mssql.c?r1=1.152.2.13.2.2&r2=1.152.2.13.2.3&pathrev=PHP_5_2
but I don't know if it is necessary or even correct. 
  
Here is the diff against PHP 5.2.3. 


diff -u /devel2/x2www/src/php-5.2.3/ext/mssql/php_mssql.c
./php_mssql.c
--- /devel2/x2www/src/php-5.2.3/ext/mssql/php_mssql.c   2007-02-24
03:17:25.0 +0100
+++ ./php_mssql.c   2007-06-04 15:37:25.265625000 +0200
@@ -814,8 +814,21 @@
 static void php_mssql_get_column_content_with_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type  TSRMLS_DC)
 {
if (dbdata(mssql_ptr->link,offset) == NULL &&
dbdatlen(mssql_ptr->link,offset) == 0) {
-   ZVAL_NULL(result);
-   return;
+#ifdef HAVE_FREETDS
+   /* double check that it is a real null, it could also
be a zero-length varchar(max) string */
+   TDSCOLUMN *colinfo;
+   TDSRESULTINFO *resinfo;
+
+   resinfo =
((DBPROCESS*)(mssql_ptr->link))->tds_socket->res_info;
+   colinfo = resinfo->columns[offset-1];
+   if (colinfo->column_cur_size < 0) {
+#endif
+   ZVAL_NULL(result);
+   return;
+#ifdef HAVE_FREETDS
+   }
+#endif
+
}
 
switch (column_type)
@@ -935,7 +948,7 @@
 
 static void php_mssql_get_column_content_without_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type TSRMLS_DC)
 {
-   if (dbdatlen(mssql_ptr->link,offset) == 0) {
+   if (dbdata(mssql_ptr->link,offset) == NULL &&
dbdatlen(mssql_ptr->link,offset) == 0) {
ZVAL_NULL(result);
return;
}
diff -u /devel2/x2www/src/php-5.2.3/ext/mssql/php_mssql.h
./php_mssql.h
--- /devel2/x2www/src/php-5.2.3/ext/mssql/php_mssql.h   2007-01-01
10:36:03.

#41539 [Com]: MSSQL ext. with freetds treats '' (string of length 0) as NULL in VARCHAR(MAX)

2007-06-18 Thread erudd at netfor dot com
 ID:   41539
 Comment by:   erudd at netfor dot com
 Reported By:  frode at coretrek dot com
 Status:   Assigned
 Bug Type: MSSQL related
 Operating System: Linux and win32
 PHP Version:  5.2.3
 Assigned To:  fmk
 New Comment:

Isn't this a dup of #39213.


Previous Comments:


[2007-06-18 20:16:31] erudd at netfor dot com

Patch Developed w/ freetds maintainer to fix this issue

--- mssql/php_mssql.c.orig  2006-04-04 14:49:12.0 -0400
+++ mssql/php_mssql.c   2006-10-24 16:41:18.0 -0400
@@ -818,7 +818,7 @@
 
 static void php_mssql_get_column_content_with_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type  TSRMLS_DC)
 {
-   if (dbdatlen(mssql_ptr->link,offset) == 0) {
+   if (dbdatlen(mssql_ptr->link,offset) == 0 &&
dbdata(mssql_ptr->link,offset) == NULL) {
ZVAL_NULL(result);
return;
}
@@ -941,7 +941,7 @@
 
 static void php_mssql_get_column_content_without_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type TSRMLS_DC)
 {
-   if (dbdatlen(mssql_ptr->link,offset) == 0) {
+   if (dbdatlen(mssql_ptr->link,offset) == 0 &&
dbdata(mssql_ptr->link,offset) == NULL) {
ZVAL_NULL(result);
return;
}



[2007-06-04 14:16:12] frode at coretrek dot com

So I had a go at hacking on the C source for the mssql extension, and I
think I have come up with some sort of solution.

First of all, it appears that the regular FreeTDS dblib api has no way
to distinguish "" from NULL for varchar(max). dbdatlen() returns 0
either way, and dbdata() returns a pointer to 0x0. 

Looking at the source code for the FreeTDS tsql application, it became
obvious that when result set columns contains a real NULL, the
"column_cur_size" is always less than 0. Relevant piece of code from
tsql.c:

  if (col->column_cur_size < 0) {
if (print_rows)
  fprintf(stdout, "NULL\t");
continue;
  }

Unfortunately, negative column_cur_size is masked in dblib. Relevant
piece of code from
dblib.c's implementation of dbdatlen():

  if (colinfo->column_cur_size < 0)
ret = 0;
  else
ret = colinfo->column_cur_size;

So it seems we need to access the low level TDS structures to tell the
difference. 
Playing around with gdb, it seems that column_cur_size is 0 for strings
and -1 for real NULLs.

So I came up with an ugly hack for php_mssql.c. It does produce the
expected output,
but it's been a long time since I did anything serious in C, so I don't
know if it is 
the correct way of doing things. 

Tested on Windows 2003 x86, compiled with Microsoft Visual C++ 2005
(Compiler version 
14.00.50727.42 for 80x86), FreeTDS 0.64, running against an instance of
SQL Server 2005,
and c:\freetds.conf contains:
[global]
  tds version = 7.0
  
  
I also added a "dbdata(..) == NULL" condition to the if()
in php_mssql_get_column_content_without_type(), just because that
function seems to be similar to
what was fixed in
http://cvs.php.net/viewcvs.cgi/php-src/ext/mssql/php_mssql.c?r1=1.152.2.13.2.2&r2=1.152.2.13.2.3&pathrev=PHP_5_2
but I don't know if it is necessary or even correct. 
  
Here is the diff against PHP 5.2.3. 


diff -u /devel2/x2www/src/php-5.2.3/ext/mssql/php_mssql.c
./php_mssql.c
--- /devel2/x2www/src/php-5.2.3/ext/mssql/php_mssql.c   2007-02-24
03:17:25.0 +0100
+++ ./php_mssql.c   2007-06-04 15:37:25.265625000 +0200
@@ -814,8 +814,21 @@
 static void php_mssql_get_column_content_with_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type  TSRMLS_DC)
 {
if (dbdata(mssql_ptr->link,offset) == NULL &&
dbdatlen(mssql_ptr->link,offset) == 0) {
-   ZVAL_NULL(result);
-   return;
+#ifdef HAVE_FREETDS
+   /* double check that it is a real null, it could also
be a zero-length varchar(max) string */
+   TDSCOLUMN *colinfo;
+   TDSRESULTINFO *resinfo;
+
+   resinfo =
((DBPROCESS*)(mssql_ptr->link))->tds_socket->res_info;
+   colinfo = resinfo->columns[offset-1];
+   if (colinfo->column_cur_size < 0) {
+#endif
+   ZVAL_NULL(result);
+   return;
+#ifdef HAVE_FREETDS
+   }
+#endif
+
}
 
switch (column_type)
@@ -935,7 +948,7 @@
 
 static void php_mssql_get_column_content_without_type(mssql_link
*mssql_ptr,int offset,zval *result, int column_type TSRMLS_DC)
 {
-   if (dbdatlen(mssql_ptr->link,offset) == 0) {
+   if (dbdata(mssql_ptr->link,offset) == NULL &&
dbdatlen(mssql_ptr->link,offset) == 0) {
ZVAL_NULL(result);
return;
  

#33153 [Asn]: segfaults when calling mssql_next_result

2005-08-03 Thread erudd at netfor dot com
 ID:   33153
 User updated by:  erudd at netfor dot com
 Reported By:  erudd at netfor dot com
 Status:   Assigned
 Bug Type: MSSQL related
-Operating System: Fedora Core 3 x86_64
+Operating System: FC3/FC4/MDK 10.2 x86 & x86_64
 PHP Version:  4.3.11
 Assigned To:  fmk
 New Comment:

Any updates on this issue? 

(Mandrake Bug #)
http://qa.mandriva.com/show_bug.cgi?id=17272


Previous Comments:


[2005-06-28 18:54:00] erudd at netfor dot com

I have tried the latest CVS code for the php-mssql extension and the
same results occur.. I updated to the lastest on the 0.63 branch of
freetds and apache/php no longer segfault, but PHP never advances to
the next result set.



[2005-05-30 10:31:51] freddyz77 at tin dot it

dblastrow should not fail, this is certainly a FreeTDS bug. Fixed in
CVS, expect a new 0.63.1 release.
However I don't understand why PHP calls dblastrow (related to dblib
buffering).

freddy77
(FreeTDS developer)



[2005-05-26 19:37:46] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





[2005-05-26 18:49:17] eddie at omegaware dot com

segfault occurs because of a null res_info in the dbproc that is passed
to the dblastrow function in freetds' dblib.

FreeTDS bug report on the issue

http://sourceforge.net/tracker/index.php?func=detail&aid=1209286&group_id=33106&atid=407806

Not sure if this is a freetds issue, or if php-mssql isn't doing
something correct.



[2005-05-26 18:23:22] eddie at omegaware dot com

Backtrace of the crash.

#0  dblastrow (dbproc=0x8c9530) at dblib.c:5909
#1  0x002a9a7f54bf in zif_mssql_next_result (ht=9213232,
return_value=0x7bde58, 
this_ptr=0x9034a0, return_value_used=9454256)
at
/home/erudd/RPMBUILD/BUILD/php-4.3.11/ext/mssql/php_mssql.c:1865
#2  0x0051c405 in execute (op_array=0x8004b8)
at /usr/src/debug/php-4.3.11/Zend/zend_execute.c:1654
#3  0x0051891b in execute (op_array=0x7f3128)
at /usr/src/debug/php-4.3.11/Zend/zend_execute.c:1698
#4  0x0051891b in execute (op_array=0x7af1b8)
at /usr/src/debug/php-4.3.11/Zend/zend_execute.c:1698
#5  0x0050869d in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/debug/php-4.3.11/Zend/zend.c:926
#6  0x004dc14a in php_execute_script
(primary_file=0x7fb550)
at /usr/src/debug/php-4.3.11/main/main.c:1745
#7  0x0052384a in main (argc=3, argv=0x7fb688)
at /usr/src/debug/php-4.3.11/sapi/cgi/cgi_main.c:1601



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
http://bugs.php.net/33153

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