Re: [Firebird-devel] Errors vector lifetime
18.11.2020 17:49, Dimitry Sibiryakov wrote: How long pointer returned from IStatus::getErrors() is supposed to be valid? I think I found a weird case. In Y-valve there is code like this: status.setErrors(status.getErrors()); During such self assignment returned pointer can be invalidated by setErrors() code before using input parameter which may cause crash or wrong result. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Errors vector lifetime
On 12/9/20 2:03 PM, Dimitry Sibiryakov wrote: 18.11.2020 17:49, Dimitry Sibiryakov wrote: How long pointer returned from IStatus::getErrors() is supposed to be valid? I think I found a weird case. In Y-valve there is code like this: status.setErrors(status.getErrors()); During such self assignment returned pointer can be invalidated by setErrors() code before using input parameter which may cause crash or wrong result. Builtin implementation works fine with your particular sample. But I fully agree that such call patterns should better be avoided (for example using Arg::StatusVector for intermediate vector). Where does it happen in yvalve? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] IStatus::setErrors() to "no errors"
On 12/8/20 8:20 PM, Dimitry Sibiryakov wrote:
08.12.2020 17:36, Alex Peshkoff via Firebird-devel wrote:
Should a custom implementation of IStatus recognize and ignore a
special case when GDS error code is set to zero using parameter (
isc_arg_gds, 0, isc_arg_end } or error with zero code is also an error?
From IStatus POV - also an error, just store what you've got on input.
In this case getState() will return STATE_ERRORS and it will be a
surprise for calling code.
That depends upon getState() internals, is not it? :)
unsigned getState() const
{
return (errors.value()[1] ? IStatus::STATE_ERRORS : 0) |
(warnings.value()[1] ? IStatus::STATE_WARNINGS : 0);
}
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Errors vector lifetime
09.12.2020 12:21, Alex Peshkoff via Firebird-devel wrote: During such self assignment returned pointer can be invalidated by setErrors() code before using input parameter which may cause crash or wrong result. Builtin implementation works fine with your particular sample. Not quite so. It works only because both errors and warning vectors used to be empty at that point so the pointers are point to the inline storage. If heap storage is used (for example after IProvider::attachDatabase() returned massive warnings), call to clean() in setWarnings() will invalidate the pointer. Where does it happen in yvalve? I've found it in Dispatcher::attachOrCreateDatabase() and Dispatcher::attachServiceManager() but there can be more. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] IStatus::setErrors() to "no errors"
09.12.2020 12:23, Alex Peshkoff via Firebird-devel wrote: That depends upon getState() internals, is not it? :) Yes. Firebird implementation recognizes zero error code in getState() so I wonder if it is a specs' requirement or such recognition can be performed in other places. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Errors vector lifetime
On 12/9/20 2:28 PM, Dimitry Sibiryakov wrote: 09.12.2020 12:21, Alex Peshkoff via Firebird-devel wrote: During such self assignment returned pointer can be invalidated by setErrors() code before using input parameter which may cause crash or wrong result. Builtin implementation works fine with your particular sample. Not quite so. It works only because both errors and warning vectors used to be empty at that point so the pointers are point to the inline storage. If heap storage is used (for example after IProvider::attachDatabase() returned massive warnings), call to clean() in setWarnings() will invalidate the pointer. setWarnings() does not use clear(), it's using save() internal call which does invalidates memory in the very end and therefore is safe Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Errors vector lifetime
09.12.2020 12:41, Alex Peshkoff via Firebird-devel wrote: setWarnings() does not use clear(), it's using save() internal call which does invalidates memory in the very end and therefore is safe Ah, I see. I looked at wrong save() overload. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] IStatus::setErrors() to "no errors"
On 12/9/20 2:31 PM, Dimitry Sibiryakov wrote: 09.12.2020 12:23, Alex Peshkoff via Firebird-devel wrote: That depends upon getState() internals, is not it? :) Yes. Firebird implementation recognizes zero error code in getState() so I wonder if it is a specs' requirement or such recognition can be performed in other places. For backward compatibility reason - people may add a call to getErrors() in one place but check result in some other passing STATUS* as parameter - IStatus implementation never returns true empty errors vector in 'no errors' state. Instead at least 3 elements are always present "1, 0, 0". I'm unsure shiuld it be treated as requirement or implementation detail, sooner second case. Checking getState() is better (and in a typical case of 'no errors' - much faster with appropriate wrapper) way to check for presence of errors. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] IMessageMetadata::get/setLength for VARCHAR
Hello All. Remember me, please, when build metadata for a record should length value provided to setLength() (and returned by getLength()) to be two bytes bigger when constructing VARCHAR field? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] IMessageMetadata::get/setLength for VARCHAR
09.12.2020 18:31, Dimitry Sibiryakov wrote: Remember me, please, when build metadata for a record should length value provided to setLength() (and returned by getLength()) to be two bytes bigger when constructing VARCHAR field? Self-answer: no, get/setLength() work with exactly declared length. It is only dsc_length is longer. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
