Bug #44618 [Ver->Csd]: Fetching may rely on uninitialized data

From: Date: Thu, 29 Oct 2020 11:05:06 +0000
Subject: Bug #44618 [Ver->Csd]: Fetching may rely on uninitialized data
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-230004@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=44618&edit=1

 ID:                 44618
 Updated by:         cmb@php.net
 Reported by:        charlie at strausesoftware dot com
 Summary:            Fetching may rely on uninitialized data
-Status:             Verified
+Status:             Closed
 Type:               Bug
 Package:            ODBC related
 Operating System:   Windows 2000
 PHP Version:        7.3
 Assigned To:        cmb
 Block user comment: N
 Private report:     N

 New Comment:

Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=c21e901ba735e927e345b65a35fcd6f585d0c2f3
Log: Fix #44618: Fetching may rely on uninitialized data


Previous Comments:
------------------------------------------------------------------------
[2020-10-06 11:38:38] cmb@php.net

The following pull request has been associated:

Patch Name: Fix #44618: Fetching may rely on uninitialized data
On GitHub:  https://github.com/php/php-src/pull/6281
Patch:      https://github.com/php/php-src/pull/6281.patch

------------------------------------------------------------------------
[2020-10-05 14:36:20] cmb@php.net

I confirm this issue with ODBC 17 Driver for SQL Server.  The ODBC
cursor library has a hard time to emulate SQLGetData()[1] which is
used by the ODBC extension to retrieve "long" data.  Given that
the ODBC cursor library is deprecated, I don't see a point in
trying to improve the current handling, except that we really need
to properly handle the SQL_NO_DATA result.

[1] <https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/sqlgetdata-cursor-library>

------------------------------------------------------------------------
[2008-04-16 15:26:31] charlie at strausesoftware dot com

On second thought, having that exact real number value in the real number field needs to be there
for the error to happen.

------------------------------------------------------------------------
[2008-04-02 19:51:18] charlie at strausesoftware dot com

Actually, it fails just on a single text column in the table. If its text. Changing it to ntext in
this case, works.

------------------------------------------------------------------------
[2008-04-02 16:15:48] charlie at strausesoftware dot com

Description:
------------
I'm using PHP with Apache. PHP code connects to MS SQL server using ODBC.

I'm doing a query against a table that is very simple: one column of the 
real data type, one of the text data type.

The text field is set to "testing 1,2,3". The real column is set to 
10.0199995.

When I use the default connect options, I get both values back fine.

When I use  SQL_CUR_USE_ODBC, which I very much want to use, then the text 
column data comes back as boolean(false).


Reproduce code:
---------------
Table:

CREATE TABLE [dbo].[test1](
[ID] [int] IDENTITY(1,1) NOT NULL,

[real1] [real] NULL,

[text1] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

CONSTRAINT [PK_test1] PRIMARY KEY CLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

Insert 1 row where text1 is set to "testing 1,2,3" and real1 is set to 10.0199995.

Code:

<?php
$conn = odbc_connect(db-name, user-name,password, SQL_CUR_USE_ODBC);
$result = odbc_exec($conn, "select * from test1");
if (odbc_fetch_row($result)) {
 print "Values: " . odbc_result($result,"real1") . "," . 
odbc_result($result,"text1");
}
?>


Expected result:
----------------
Values: 10.02,testing 1,2,3 

Actual result:
--------------
Values: 10.02, 


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



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


Thread (6 messages)

« previous php.bugs (#230004) next »