Charles Jardine wrote:
On 28/01/10 13:15, Martin Evans wrote:
> Charles Jardine wrote:
>> On 27/01/10 17:38, Martin Evans wrote:
[snip]
>> I prefer his version, with the cast to site_t left where it was,
>> rather than imported into the macro.
>
> I'm not that comfortable with the cast to size_t in dbdimp.c
> because then it is later cast back to unsigned long and I'd guess
> on platforms where size_t is an unsigned long long the compiler
> might whine about that.
>
> The best fix would be if there was a reliable format for size_t but
> I don't know of one.
Many modern printf implementations support 'z' as a width modifier
meaning 'as wide as size_t'. This makes '%zu' the right answer fro
such implementations. However, PerlIO_printf does not support it, so
we can't use it.
yes, it is a shame. There are macros in perl for IV, UV etc format
strings but none for size_t that I have ever seen.
There are also a lot of perl internal macros generating a lot of gcc
warnings. I see these
in DBD::Oracle and DBD::ODBC.
> However, I don't think we need to get this out of proportion after
> all it is only two calls and in both cases the size_t is 0 anyway
> as the requested attributes are integers and not strings.
Indeed!
Good :-)
>> If the current SVN version works for Martin, I suggest that no
>> more needs to be done.
>
> It does work.
Excellent.
[bug report snipped]
> I suggest we try very hard to get someone with a 64bit platform to
> try the next RC.
I will be testing RC5 on as 64-bit Linux platform with Oracle
10.2.0.4.3. If you want me to test anything specific, let me know.
I have a large test case here which I run and there is one outstanding
issue I know about which I have a) reported here and b) have not found
the solution for yet. However, I cannot run my tests with ora_verbose
set so if you can do some testing with that set it would be useful. I'm
guessing from your previous posts you'll be keen to ensure oracle
objects work and we heavily use lob locators, rowcachesize and reference
cursors which I will be looking at.
Thanks.
Martin
