Issue Details (XML | Word | Printable)

Key: CORE-2550
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Bus error when working with DB_KEY on bigendian machines

Created: 08/Jul/09 07:15 AM   Updated: 16/Jan/13 05:43 PM
Component/s: Engine
Affects Version/s: 2.1.2, 2.5 Beta 1
Fix Version/s: 2.5 Beta 2, 2.1.3

Time Tracking:
Not Specified

Environment: SPARC Solaris (looks like can affect any bigendian)

Planning Status: Unspecified


 Description  « Hide
When working with DB_KEY in stored procedure, alignment error takes place. Tjhis happens due to badly aligned data in descriptor, storing DB_KEY as text, and direct reintepret_cast<>, applied to it in evl.cpp:

RecordNumber::Packed* numbers = reinterpret_cast<RecordNumber::Packed*>(desc->dsc_address);

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 10/Jul/09 04:11 AM
2.1 codebase has simplified fix, forcing alignment of descriptor data on bigendian machines.

In HEAD new descriptor type is added in engine, dtype_dbkey. It's never goes out of engine in 2.5 (even dsql knows nothing about it). In the future new type should be also added to XSQLDA and related places, helping void hacks in isql and other clients when displaying DB_KEY.

Alexander Peshkov added a comment - 10/Jul/09 04:53 AM
Reopened to modify fix version - decided to have it in 2.1.3 RC2.

Dmitry Yemanov added a comment - 16/Jan/13 05:43 PM
Just for the record, I disagree with the DBKEY being surfaced in XSQLDA as a separate datatype. The XSQLVAR types are needed just to map FB datatypes to the host language datatypes. If one can work with DBKEYs in PSQL using SQL datatypes, the same can be easily done in the host language using existing XSQLVAR datatypes. As for informing the user about some var being a DBKEY (for displaying purposes or whatever), other solutions are possible (e.g. some flag returned for the every described parameter).