On 22-05-2021 12:03, Dimitry Sibiryakov wrote:
22.05.2021 11:10, Karol Bieniaszewski wrote:
And the final conclusion why new API is better then old one as it was
accepted and preffered.
For application development new API isn't better than old one. Its
aim is Firebird plugins development
22.05.2021 11:10, Karol Bieniaszewski wrote:
Isn’t such documentation already available by the new API developers?
No.
Its benefits, comparision with simplicity about use, speed, memory usage,
extenibility..
Nothing like this.
And the final conclusion why new API is better then old
Isn’t such documentation already available by the new API developers?
I cannot imagine to have not comparision between every code in old vs new api.
Its benefits, comparision with simplicity about use, speed, memory usage,
extenibility..
And the final conclusion why new API is better then old one
>> Also, I had plans to implement unlimited (well, OK, ULONG-counted) strings
>> in the next major ODS. This really requires more API changes than some hacks
>> with the sign bitWhen introduced then will be good to describe
>> benefits/weekness of using varchar vs blob in such
>> For example - make all sizes uint32Why not uint64?Regards,Karol Bieniaszewski
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 22-05-2021 09:19, Dmitry Yemanov wrote:
22.05.2021 10:06, Mark Rotteveel wrote:
The majority of our users probably still use the old API, either
directly or indirectly. Given the undocumented state of the new API, I
suspect it does not see a lot of usage, nor will it unless that changes.
22.05.2021 10:06, Mark Rotteveel wrote:
The majority of our users probably still use the old API, either
directly or indirectly. Given the undocumented state of the new API, I
suspect it does not see a lot of usage, nor will it unless that changes.
Introducing features that only benefit
22.05.2021 09:58, Mark Rotteveel wrote:
In any case, I think adding 1 to a length to obtain the actual length is
a bad idea even if it is not exposed to the outside. Doing that is a
great way to introduce increased risk of off-by-one errors and buffer
overflows; the risk of that increases
On 21-05-2021 20:19, Adriano dos Santos Fernandes wrote:
On 21/05/2021 11:51, Alex Peshkoff via Firebird-devel wrote:
And if we do change SQLDA_VERSION it's worth changing something else in
it. For example - make all sizes uint32, add separate field for charset,
may be something else?
My aim
On 21-05-2021 22:39, Alex Peshkoff via Firebird-devel wrote:
On 5/21/21 9:06 PM, Mark Rotteveel wrote:
On 2021-05-21 16:51, Alex Peshkoff via Firebird-devel wrote:
We have one more unused value for size - zero, we do not support
characters with length == 0.
We may store logical data length -
10 matches
Mail list logo
