Skip Menu |
 

This queue is for tickets about the DBD-ODBC CPAN distribution.

Report information
The Basics
Id: 83083
Status: resolved
Priority: 0/
Queue: DBD-ODBC

People
Owner: Nobody in particular
Requestors: ribasushi [...] leporine.io
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: Miscellaneous compile warnings
Download (untitled) / with headers
text/plain 2.7k
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]
Download (untitled) / with headers
text/plain 838b
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
Download (untitled) / with headers
text/plain 1.1k
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';
Download (untitled) / with headers
text/plain 2.8k
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
Download (untitled) / with headers
text/plain 3.4k
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.