DBD::Oracle 1.26 new_tablename / synonyms issue

[Jan Pazdziora]

Hello,

The DBD::Oracle 1.26 code

http://cpansearch.perl.org/src/TIMB/DBD-Oracle-1.26/oci8.c

declares

char new_tablename[100];

in the if branch in init_lob_refetch, and then assigns

tablename=new_tablename;

and then uses the tablename outside of that if block. So the
tablename pointer points to a random address on the stack.

It causes problems described at

http://rt.cpan.org/Public/Bug/Display.html?id=61511
https://bugzilla.redhat.com/show_bug.cgi?id=548489

Note that it's kinda related to

http://rt.cpan.org/Public/Bug/Display.html?id=36069#txn-464638

where it's said

Used some of the code form the patch there was no need to
create a char [100] outside the if statement though.

I'd claim that it is actually necessary to declare it outside of
that block because even if the name goes out of scope at the end
of the block, the tablename pointer still points to it.

Please apply

--- oci8.c.orig 2010-11-16 16:26:42.459208675 +0100
+++ oci8.c  2010-11-16 16:27:27.194207404 +0100
@@ -4030,6 +4030,7 @@
ub2 numcols = 0;
imp_fbh_t *fbh;
int unmatched_params;
+   char new_tablename[100];
I32 i,j;
char *p;
lob_refetch_t *lr = NULL;
@@ -4067,7 +4068,6 @@
if (status == OCI_SUCCESS) { /* There is a synonym, get the schema */
char *syn_schema=NULL;
char syn_name[100];
-   char new_tablename[100];
ub4  tn_len = 0, syn_schema_len = 0;
 
strncpy(syn_name,tablename,strlen(tablename));

to DBD::Oracle.

Thank you,

-- 
Jan Pazdziora

Re: Multiple directories for 'f_dir' parameter for DBD::File (especially DBD::CSV)

[H.Merijn Brand]

On Tue, 16 Nov 2010 07:46:53 +0100, Jens Rehsack
rehs...@googlemail.com wrote:

 Hi all,
 
 in an application (I call it App::Automated::Letter) I will process
 some csv databases (OpenOffice.org/Excel exported files). I'd like
 to allow the application to find the appropriate csv file (table name
 for automated letter processing run will be specified per run or on
 command line) in a list of directories (e.g. ['.',
 '$HOME/Documents',
 '$HOME/Letter', ...]).
 
 I'd like to point on the field of operation: desktop end users -
 totally different from administrators, operators etc. :)
 
 Would anyone mind when I patch DBD::File to accept a list of
 directories in f_dir and search for a matching db-file in this list?

Why not just create a pool of database handles instead?

 I thought about using an 'f_dir_list', too - but there're always users
 who would try to specify both and than a behavior must exist for such
 a situation. If the 'f_dir_list' is preferred - such a behavior must
 be defined, too.
 
 Best regards,
 Jens


-- 
H.Merijn Brand  http://tux.nl  Perl Monger  http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org/
http://qa.perl.org  http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Multiple directories for 'f_dir' parameter for DBD::File (especially DBD::CSV)

[Jens Rehsack]

2010/11/16 Reinier Post r...@win.tue.nl:
 On Tue, Nov 16, 2010 at 07:46:53AM +0100, Jens Rehsack wrote:

 Would anyone mind when I patch DBD::File to accept a list of
 directories in f_dir
 and search for a matching db-file in this list?

 I thought about using an 'f_dir_list', too - but there're always users
 who would try to
 specify both and than a behavior must exist for such a situation. If
 the 'f_dir_list'
 is preferred - such a behavior must be defined, too.

 Is this problem DBD::File-specific?

This is DBD::File and derived specific.

 What about SQLite3 databases?

Left untouched.

Jens