[Oledb-dev] Provider question

[Arvo]

Hello Shachar,

> Just a word of advice. Putting casts any where the compiler complains is
> easy. The difficult part is understanding whether the cast is dangerous,
> and whether the cast should be skipped in favor of changing the return
> code of the function.

I know, that's why I didn't post blind patches (at least not every possible patch :)).

>>Some ideas to make some warnings (including in atldb.h) disappear:
>>
>>PgRs.h, line 73+:
>>
>>    size_t GetCount() const
>>    {
>>        return GetSize();
>>    }
>>
>>  
>>
> I'm assuming you meant changing the GetSize return type as well....

NO. I can't see VC6 ATL declarations - maybe they are different.

> GetCount/GetSize is not a function which is our idea. It is mandated by
> the ATL template we use. Before changing its return type, we need to
> find out:
> 1. Is the function documented in MSDN, and if so, what return type is
> listed for it?

If I understand correctly, then we should look at CAtlArray. See here:
http://msdn2.microsoft.com/en-us/library/fw0hk9ew.aspx

size_t seems the right choice.

>>TypeInfo.cpp, line 240+:
>>
>>{
>>    ATLASSERT(count>=(size_t)GetWidth_string( sess, res, tup_num, field_num ));
>>    int reslen=PQgetlength( res, tup_num, field_num );
>>  
>>
> GetWidth_string is a function who's interface we defined. We do not need
> to follow any external protocol with it. However, the question about
> reserved negative returns still holds.

Not likely. This GetWidth_string returns value of PG lib function int PQgetlength(), which actually uses 0 [zero] for error situations and some res->tuples[tup_num][field_num].len value, which IMHO can be negative only when field has NULL value, but PQgetlength returns 0 in that case too :). Well, I didn't dive deeper into PG code.

Well, maybe better would be redeclare GetWidth_string (and other GetWidth_) as size_t. But I need to look further, there are lot of various *Width* functions.

Of course this all is not so important than would be driver functional development, but anyway.

-- 
Best regards,
 Arvo                            mailto:arvox at hot.ee