Bug #83083 for DBD-ODBC: Miscellaneous compile warnings

Fri Feb 01 01:20:12 2013 ribasushi [...] leporine.io - Ticket created

Subject:

Miscellaneous compile warnings

Hi Martin, Tested latest DBD::ODBC, seems to work great. However a number of warnings scrolled by at compilation time. The 'duplicate function definition' one is particularly ominous. Cheers cc -c -I/usr/include -I. -I/home/rabbit/perl5/perlbrew/perls/5.17.8/lib/site_perl/5.17.8/x86_64-linux-thread-multi-64int-ld/auto/DBI -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.42_5\" -DXS_VERSION=\"1.42_5\" -fPIC "-I/home/rabbit/perl5/perlbrew/perls/5.17.8/lib/5.17.8/x86_64-linux-thread-multi-64int-ld/CORE" -I/usr/include ConvertUTF.c /home/rabbit/perl5/perlbrew/perls/5.17.8/bin/perl5.17.8 -p -e "s/~DRIVER~/ODBC/g" /home/rabbit/perl5/perlbrew/perls/5.17.8/lib/site_perl/5.17.8/x86_64-linux-thread-multi-64int-ld/auto/DBI/Driver.xst Show quoted text

> ODBC.xsi

/home/rabbit/perl5/perlbrew/perls/5.17.8/bin/perl5.17.8 /home/rabbit/perl5/perlbrew/perls/5.17.8/lib/5.17.8/ExtUtils/xsubpp -typemap /home/rabbit/perl5/perlbrew/perls/5.17.8/lib/5.17.8/ExtUtils/typemap ODBC.xs > ODBC.xsc && mv ODBC.xsc ODBC.c Warning: duplicate function definition 'data_sources' detected in ODBC.xs, line 482 cc -c -I/usr/include -I. -I/home/rabbit/perl5/perlbrew/perls/5.17.8/lib/site_perl/5.17.8/x86_64-linux-thread-multi-64int-ld/auto/DBI -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.42_5\" -DXS_VERSION=\"1.42_5\" -fPIC "-I/home/rabbit/perl5/perlbrew/perls/5.17.8/lib/5.17.8/x86_64-linux-thread-multi-64int-ld/CORE" -I/usr/include ODBC.c cc -c -I/usr/include -I. -I/home/rabbit/perl5/perlbrew/perls/5.17.8/lib/site_perl/5.17.8/x86_64-linux-thread-multi-64int-ld/auto/DBI -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.42_5\" -DXS_VERSION=\"1.42_5\" -fPIC "-I/home/rabbit/perl5/perlbrew/perls/5.17.8/lib/5.17.8/x86_64-linux-thread-multi-64int-ld/CORE" -I/usr/include dbdimp.c dbdimp.c: In function ‘odbc_set_query_timeout’: dbdimp.c:197:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dbdimp.c: In function ‘odbc_db_STORE_attrib’: dbdimp.c:4660:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dbdimp.c: In function ‘set_odbc_version’: dbdimp.c:6400:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dbdimp.c: In function ‘post_connect’: dbdimp.c:6671:36: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dbdimp.c: In function ‘odbc_st_execute_for_fetch’: dbdimp.c:7164:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

Sun Feb 03 06:10:11 2013 bohica [...] ntlworld.com - Correspondence added

On Fri Feb 01 01:20:12 2013, RIBASUSHI wrote: Show quoted text

> Hi Martin, > > Tested latest DBD::ODBC, seems to work great. However a number of > warnings scrolled by at compilation time. The 'duplicate function > definition' one is particularly ominous. > > Cheers

Thanks Peter. The duplicate function warning has been there since before I took over maintenance. I did look into years ago and and decided it was nothing to worry about but I guess I should convince myself of that. The other warnings are due to casting SQLINTEGER to SQLPOINTER (where on all platforms I know a SQLPOINTER is larger than an SQLINTEGER) and it occurs because SQLSetXXXAttr functions are multipurpose. They can be used for setting integer values or pointer values so the argument is defined as a SQLPOINTER and hence the cast. Martin -- Martin J. Evans Wetherby, UK

Sun Feb 03 06:10:13 2013 The RT System itself - Status changed from 'new' to 'open'

Tue Feb 26 07:03:35 2013 ribasushi [...] leporine.io - Correspondence added

On Sun Feb 03 06:10:11 2013, MJEVANS wrote: Show quoted text

> On Fri Feb 01 01:20:12 2013, RIBASUSHI wrote:

> > Hi Martin, > > > > Tested latest DBD::ODBC, seems to work great. However a number of > > warnings scrolled by at compilation time. The 'duplicate function > > definition' one is particularly ominous. > > > > Cheers

> > Thanks Peter. > > The duplicate function warning has been there since before I took over > maintenance. I did look into years ago and and decided it was nothing to > worry about but I guess I should convince myself of that.

Neh - if you say it is ok - it is ok ;) Show quoted text

> The other warnings are due to casting SQLINTEGER to SQLPOINTER (where on > all platforms I know a SQLPOINTER is larger than an SQLINTEGER) and it > occurs because SQLSetXXXAttr functions are multipurpose. They can be > used for setting integer values or pointer values so the argument is > defined as a SQLPOINTER and hence the cast.

I see... but then why does the compiler issue a warning - doesn't it use the sizes of the current system to decide what is a "different size"? The reason I am trying to clarify this is because most of my perlbrews look like this: rabbit@Thesaurus:~$ perl '-V:ivsize|ptrsize' ivsize='8'; ptrsize='4';

Tue Feb 26 09:06:51 2013 bohica [...] ntlworld.com - Correspondence added

On Tue Feb 26 07:03:35 2013, RIBASUSHI wrote: Show quoted text

> On Sun Feb 03 06:10:11 2013, MJEVANS wrote:

> > On Fri Feb 01 01:20:12 2013, RIBASUSHI wrote:

> > > Hi Martin, > > > > > > Tested latest DBD::ODBC, seems to work great. However a number of > > > warnings scrolled by at compilation time. The 'duplicate function > > > definition' one is particularly ominous. > > > > > > Cheers

> > > > Thanks Peter. > > > > The duplicate function warning has been there since before I took over > > maintenance. I did look into years ago and and decided it was nothing to > > worry about but I guess I should convince myself of that.

> > Neh - if you say it is ok - it is ok ;) >

> > The other warnings are due to casting SQLINTEGER to SQLPOINTER (where on > > all platforms I know a SQLPOINTER is larger than an SQLINTEGER) and it > > occurs because SQLSetXXXAttr functions are multipurpose. They can be > > used for setting integer values or pointer values so the argument is > > defined as a SQLPOINTER and hence the cast.

> > I see... but then why does the compiler issue a warning - doesn't it use > the sizes of the current system to decide what is a "different size"? > The reason I am trying to clarify this is because most of my perlbrews > look like this: > > rabbit@Thesaurus:~$ perl '-V:ivsize|ptrsize' > ivsize='8'; > ptrsize='4'; >

ivsize has nothing to do with it as the code does not pass an IV to an ODBC APIs. The size of SQLINTEGER is the one that matters as it is this which is cast to an SQLPOINTER. SQLINTEGER is always smaller or the same size as an SQLPOINTER on all platforms I've seen. The problem is some ODBC APIs are general purpose and might need a pointer argument or an integer argument. In these case MS define the argument as an SQLPOINTER and if the SQLSet* call I'm making to set a connection or statement attribute is an integer value I have to cast to SQLPOINTER or the compiler will warn (e.g., setting auto commit is an on/off value of 1 or 0 but the argument is an SQLPOINTER). SQLINTEGER is 4 bytes on all platforms I've even seen. MS introduced SQLULEN/SQLLEN for 64 bit integers. Does thi help convince you: sources@fc64:~/martin$ cat rt83083.c #include <stdio.h> #include <sql.h> #include <sqltypes.h> int main() { SQLINTEGER i; SQLPOINTER p; printf("sizeof(SQLINTEGER)=%lu\n", sizeof(SQLINTEGER)); printf("sizeof(SQLPOINTER)=%lu\n", sizeof(SQLPOINTER)); i = 1; p = i; printf("p = %p\n", p); p = (SQLPOINTER)i; printf("p = %p\n", p); return 0; } sources@fc64:~/martin$ gcc -I /usr/local/easysoft/unixODBC/include/ -Wall rt83083.c rt83083.c: In function ‘main’: rt83083.c:12: warning: assignment makes pointer from integer without a cast rt83083.c:14: warning: cast to pointer from integer of different size sources@fc64:~/martin$ ./a.out sizeof(SQLINTEGER)=4 sizeof(SQLPOINTER)=8 p = 0x1 p = 0x1 Martin -- Martin J. Evans Wetherby, UK

Sat Sep 07 12:59:24 2013 bohica [...] ntlworld.com - Correspondence added

On Tue Feb 26 09:06:51 2013, MJEVANS wrote: Show quoted text

> On Tue Feb 26 07:03:35 2013, RIBASUSHI wrote:

> > On Sun Feb 03 06:10:11 2013, MJEVANS wrote:

> > > On Fri Feb 01 01:20:12 2013, RIBASUSHI wrote:

> > > > Hi Martin, > > > > > > > > Tested latest DBD::ODBC, seems to work great. However a number of > > > > warnings scrolled by at compilation time. The 'duplicate function > > > > definition' one is particularly ominous. > > > > > > > > Cheers

> > > > > > Thanks Peter. > > > > > > The duplicate function warning has been there since before I took over > > > maintenance. I did look into years ago and and decided it was nothing to > > > worry about but I guess I should convince myself of that.

> > > > Neh - if you say it is ok - it is ok ;) > >

> > > The other warnings are due to casting SQLINTEGER to SQLPOINTER (where on > > > all platforms I know a SQLPOINTER is larger than an SQLINTEGER) and it > > > occurs because SQLSetXXXAttr functions are multipurpose. They can be > > > used for setting integer values or pointer values so the argument is > > > defined as a SQLPOINTER and hence the cast.

> > > > I see... but then why does the compiler issue a warning - doesn't it use > > the sizes of the current system to decide what is a "different size"? > > The reason I am trying to clarify this is because most of my perlbrews > > look like this: > > > > rabbit@Thesaurus:~$ perl '-V:ivsize|ptrsize' > > ivsize='8'; > > ptrsize='4'; > >

> > ivsize has nothing to do with it as the code does not pass an IV to an > ODBC APIs. The size of SQLINTEGER is the one that matters as it is this > which is cast to an SQLPOINTER. SQLINTEGER is always smaller or the same > size as an SQLPOINTER on all platforms I've seen. > > The problem is some ODBC APIs are general purpose and might need a > pointer argument or an integer argument. In these case MS define the > argument as an SQLPOINTER and if the SQLSet* call I'm making to set a > connection or statement attribute is an integer value I have to cast to > SQLPOINTER or the compiler will warn (e.g., setting auto commit is an > on/off value of 1 or 0 but the argument is an SQLPOINTER). > > SQLINTEGER is 4 bytes on all platforms I've even seen. MS introduced > SQLULEN/SQLLEN for 64 bit integers. > > Does thi help convince you: > > sources@fc64:~/martin$ cat rt83083.c > #include <stdio.h> > #include <sql.h> > #include <sqltypes.h> > > int main() { > SQLINTEGER i; > SQLPOINTER p; > > printf("sizeof(SQLINTEGER)=%lu\n", sizeof(SQLINTEGER)); > printf("sizeof(SQLPOINTER)=%lu\n", sizeof(SQLPOINTER)); > i = 1; > p = i; > printf("p = %p\n", p); > p = (SQLPOINTER)i; > printf("p = %p\n", p); > > return 0; > } > sources@fc64:~/martin$ gcc -I /usr/local/easysoft/unixODBC/include/ > -Wall rt83083.c > rt83083.c: In function ‘main’: > rt83083.c:12: warning: assignment makes pointer from integer without a cast > rt83083.c:14: warning: cast to pointer from integer of different size > sources@fc64:~/martin$ ./a.out > sizeof(SQLINTEGER)=4 > sizeof(SQLPOINTER)=8 > p = 0x1 > p = 0x1 > > Martin

There really is no way I can find around these 4 warnings. SQLPOINTER is always bigger or at least the same size as SQLUINTEGER. I cannot control the ODBC API which defines the arguments to SQLSetConnectAttr as SQLPOINTER and SQL_AUTOCOMMIT_ON etc as 0UL. They've been this way for over 10 years without issues so reluctantly I'm marking this done. If you have a compelling argument to reopen then by all means do. Martin -- Martin J. Evans Wetherby, UK

Sat Sep 07 12:59:44 2013 bohica [...] ntlworld.com - Status changed from 'open' to 'resolved'