Some bug fixes and improvements - Mailing list pgsql-odbc

From Tsunakawa, Takayuki
Subject Some bug fixes and improvements
Date
Msg-id 0A3221C70F24FB45833433255569204D1F53B952@G01JPEXMBYT05
Whole thread Raw
Responses Re: Some bug fixes and improvements
List pgsql-odbc
Hello, Inoue-san and all,

While I'm learning the psqlODBC source code and investigating the cause of the scroll cursor crash problem I reported
inJanuary, I found some bugs and useless code fragments.  Please find the attached patches to remove them.  I hope
thesewill be included in the next release. 

However, I've not been able to find the cause of the crash.  The code of psqlODBC is pretty complex, particularly
aroundhandling cursors, isn't it? 

The below are the brief descriptions of the patches:


[bind_mem_failure.patch]
The existing memory is not freed upon realloc() failure.

PGAPI_BindCol() doesn't check the failure of extend_getdata_info().


[duplicate_env_alloc.patch]
setup.c:test_connection() calls EN_Constructor() twice, leaking small memory.


[flag_overwrite.patch]
Checking a flag bit mistakenly resets other flag bits.  I don't know what failure this would cause.



[ineffective_code.patch]
The third stricmp() in writeDriverCommoninfo() is useless, because the second one causes the function to return.

SC_get_errormsg() definition is repeated twice in succession.

CC_on_abort_partial() is not used.

In info.c:SQLGetInfo(), "len = 0" is unnecessary because len is assigned at the end of the function.

In execute.c:PGAPI_ExecDirect(), flag doesn't need to be set as its value doesn't change.

PODBC_PER_STATEMENT_ROLLBACK is not used.


[multi_stmt_prepare.patch]
The statement linked list is not properly chained, which throws away some statements.  I don't know what failure this
wouldcause. 


[win_build.patch]
LINKMT is not used in the build process.

ADDL_INC should be ADD_INC.  Just a typo.

The CLEAN target doesn't delete .pdb files.

Regards
Takayuki Tsunakawa


Attachment

pgsql-odbc by date:

Previous
From: Fernando Luna
Date:
Subject: Question regarding accessing only tables to which the user has access
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: Question regarding accessing only tables to which the user has access