11.09.2019 15:48, Alex Peshkoff via Firebird-devel wrote:
if you mean getParam(n) together with getNumberOfParams() - I tend to agree.
I see no need in getNumberOfParams, but may be someone does.
I'm afraid that getting data by attribute like 'name of failed FK' is close to AI task. If we ex
On 11.09.2019 16:19, Dimitry Sibiryakov wrote:
11.09.2019 15:05, Alex Peshkoff via Firebird-devel wrote:
One more related idea - return text in firebird-allocated buffer
which is later released by explicit cliens call.
The main visible disadvantage is possible deadlock when error is OOM.
If
On 11.09.2019 12:59, Dimitry Sibiryakov wrote:
11.09.2019 9:13, Alex Peshkoff via Firebird-devel wrote:
No other method - but if you have reasonable suggestion we will be
happy to implement it. Just an idea - language details are not needed.
How about an iterator on error lines? It could hav
On 11.09.2019 16:07, Jiří Činčura wrote:
No - at least in advance. What can be done is request to calculate it.
Is that in API today?
No.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
11.09.2019 15:05, Alex Peshkoff via Firebird-devel wrote:
One more related idea - return text in firebird-allocated buffer which is later released
by explicit cliens call.
The main visible disadvantage is possible deadlock when error is OOM.
If you return not plain pointer but a smart one yo
> No - at least in advance. What can be done is request to calculate it.
Is that in API today?
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 11.09.2019 11:32, Jiří Činčura wrote:
No other method - but if you have reasonable suggestion we will be happy
to implement it. Just an idea - language details are not needed.
Is the size of the message known?
No - at least in advance. What can be done is request to calculate it.
That wou
11.09.2019 9:13, Alex Peshkoff via Firebird-devel wrote:
No other method - but if you have reasonable suggestion we will be happy to implement it.
Just an idea - language details are not needed.
How about an iterator on error lines? It could have methods like getGdsCode(),
getLine(), getPara
On 11-9-2019 10:31, Jiří Činčura wrote:
In other words, this is a buffer overflow risk?
Nope. You just might to loose some part of the message if it's longer, because
it will not fit into buffer.
A right, I had overlooked the use of sizeof.
Mark
--
Mark Rotteveel
Firebird-Devel mailing li
> No other method - but if you have reasonable suggestion we will be happy
> to implement it. Just an idea - language details are not needed.
Is the size of the message known? That would allow to either allocate the right
size buffer or have some logic on upper limit.
--
Mgr. Jiří Činčura
http
> In other words, this is a buffer overflow risk?
Nope. You just might to loose some part of the message if it's longer, because
it will not fit into buffer.
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/list
On 11-9-2019 09:13, Alex Peshkoff via Firebird-devel wrote:
On 10.09.2019 18:32, Jiří Činčura wrote:
Hi *,
every example I've found uses this structure:
catch (const FbException& error)
{
char buf[256];
utl->formatStatus(buf, sizeof(buf), error.getStatus());
// ...
}
Is is guaranteed
On 10.09.2019 18:32, Jiří Činčura wrote:
Hi *,
every example I've found uses this structure:
catch (const FbException& error)
{
char buf[256];
utl->formatStatus(buf, sizeof(buf), error.getStatus());
// ...
}
Is is guaranteed that the 256 buffer is enough?
Not - though given buffer ap
Hi *,
every example I've found uses this structure:
catch (const FbException& error)
{
char buf[256];
utl->formatStatus(buf, sizeof(buf), error.getStatus());
// ...
}
Is is guaranteed that the 256 buffer is enough? I'm no expert in C++, but I
would expect no and hence some other way to get
14 matches
Mail list logo
