memory destruction in 6.4

Tatsuo Ishii wrote:

While investigating a user's complaint, I have found some memory
destructions in 6.4 source using purify.

(1) parser/gram.y:fmtId()

It writes n+3 bytes into n+1 byte-long memory area if mixed case or
non-ascii identifiers given.

Could that be also the cause for the two bugs that I have been reported
some time ago occuring when object names contain spaces ?

PostgreSQL 6.4 on RedHat Linux i386, 2.0.36 Kernel

THE FIRST ONE
=============
test=>create table students (id int4, name text);
CREATE
test=> create view "my view" as select * from students;
CREATE
test=> select * from "my view";
ERROR: nodeRead: Bad type 0

THE SECOND ONE
==============
test=> create sequence student_id;
CREATE
test=> create table "my students" (id int4 default
nextval('student_id'), name text);
ERROR: my: Table does not exist.

--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

Tatsuo Ishii wrote:

While investigating a user's complaint, I have found some memory
destructions in 6.4 source using purify.

(1) parser/gram.y:fmtId()

It writes n+3 bytes into n+1 byte-long memory area if mixed case or
non-ascii identifiers given.

Could that be also the cause for the two bugs that I have been reported
some time ago occuring when object names contain spaces ?

PostgreSQL 6.4 on RedHat Linux i386, 2.0.36 Kernel

THE FIRST ONE
=============
test=>create table students (id int4, name text);
CREATE
test=> create view "my view" as select * from students;
CREATE
test=> select * from "my view";
ERROR: nodeRead: Bad type 0

THE SECOND ONE
==============
test=> create sequence student_id;
CREATE
test=> create table "my students" (id int4 default
nextval('student_id'), name text);
ERROR: my: Table does not exist.

Sorry, but my patches seem not to fix your problems.
--
Tatsuo Ishii

Applied to both trees.

While investigating a user's complaint, I have found some memory
destructions in 6.4 source using purify.

(1) parser/gram.y:fmtId()

It writes n+3 bytes into n+1 byte-long memory area if mixed case or
non-ascii identifiers given.

(2) catalog/index.c:

ATTRIBUTE_TUPLE_SIZE bytes are allocated but
sizeof(FormData_pg_attribute) bytes are written. Note that
ATTRIBUTE_TUPLE_SIZE is smaller than
sizeof(FormData_pg_attribute). (for example, on solaris 2.6,
ATTRIBUTE_TUPLE_SIZE is 3 bytes smaller).

Attached patches try to fix the problem. I do not check all of sources 
and there may be similar mistakes remained, however.
--
Tatsuo Ishii
----------------------------- cut here -----------------------------------
*** postgresql-v6.4/src/backend/parser/gram.y.orig	Tue Dec  8 11:26:32 1998
--- postgresql-v6.4/src/backend/parser/gram.y	Tue Dec  8 11:27:00 1998
***************
*** 5125,5131 ****
if (! (islower(*cp) || isdigit(*cp) || (*cp == '_'))) break;

if (*cp != '\0') {
! 		cp = palloc(strlen(rawid)+1);
strcpy(cp,"\"");
strcat(cp,rawid);
strcat(cp,"\"");
--- 5125,5131 ----
if (! (islower(*cp) || isdigit(*cp) || (*cp == '_'))) break;

if (*cp != '\0') {
! 		cp = palloc(strlen(rawid)+3);
strcpy(cp,"\"");
strcat(cp,rawid);
strcat(cp,"\"");
*** postgresql-v6.4/src/backend/catalog/index.c.orig	Tue Dec  8 11:41:20 1998
--- postgresql-v6.4/src/backend/catalog/index.c	Tue Dec  8 14:14:29 1998
***************
*** 649,655 ****
value[Anum_pg_attribute_attcacheoff - 1] = Int32GetDatum(-1);

init_tuple = heap_addheader(Natts_pg_attribute,
! sizeof *(indexRelation->rd_att->attrs[0]),
(char *) (indexRelation->rd_att->attrs[0]));

hasind = false;
--- 649,655 ----
value[Anum_pg_attribute_attcacheoff - 1] = Int32GetDatum(-1);

init_tuple = heap_addheader(Natts_pg_attribute,
! ATTRIBUTE_TUPLE_SIZE,
(char *) (indexRelation->rd_att->attrs[0]));

hasind = false;
***************
*** 689,695 ****
*/
memmove(GETSTRUCT(cur_tuple),
(char *) indexTupDesc->attrs[i],
! sizeof(FormData_pg_attribute));

value[Anum_pg_attribute_attnum - 1] = Int16GetDatum(i + 1);

--- 689,695 ----
*/
memmove(GETSTRUCT(cur_tuple),
(char *) indexTupDesc->attrs[i],
! 			        ATTRIBUTE_TUPLE_SIZE);

value[Anum_pg_attribute_attnum - 1] = Int16GetDatum(i + 1);

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Added to TODO:

* views with spaces in view name fail when referenced

Tatsuo Ishii wrote:

While investigating a user's complaint, I have found some memory
destructions in 6.4 source using purify.

(1) parser/gram.y:fmtId()

It writes n+3 bytes into n+1 byte-long memory area if mixed case or
non-ascii identifiers given.

Could that be also the cause for the two bugs that I have been reported
some time ago occuring when object names contain spaces ?

PostgreSQL 6.4 on RedHat Linux i386, 2.0.36 Kernel

THE FIRST ONE
=============
test=>create table students (id int4, name text);
CREATE
test=> create view "my view" as select * from students;
CREATE
test=> select * from "my view";
ERROR: nodeRead: Bad type 0

THE SECOND ONE
==============
test=> create sequence student_id;
CREATE
test=> create table "my students" (id int4 default
nextval('student_id'), name text);
ERROR: my: Table does not exist.

--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Applied to both trees.

While investigating a user's complaint, I have found some memory
destructions in 6.4 source using purify.

(1) parser/gram.y:fmtId()

It writes n+3 bytes into n+1 byte-long memory area if mixed case or
non-ascii identifiers given.

(2) catalog/index.c:

ATTRIBUTE_TUPLE_SIZE bytes are allocated but
sizeof(FormData_pg_attribute) bytes are written. Note that
ATTRIBUTE_TUPLE_SIZE is smaller than
sizeof(FormData_pg_attribute). (for example, on solaris 2.6,
ATTRIBUTE_TUPLE_SIZE is 3 bytes smaller).

Attached patches try to fix the problem. I do not check all of sources
and there may be similar mistakes remained, however.
--
Tatsuo Ishii

Thank you for taking care of my patches.
---
Tatsuo Ishii