On 09/30/11 20:19, Adriano dos Santos Fernandes wrote:
> Hi!
>
> Look at this piece. The original code wastes 8 bytes per Record variable
> in 64-bits.
>
> Do you see any problem with this change?
>
> ----------------
> diff --git a/src/jrd/req.h b/src/jrd/req.h
> index 8271b3e..7db0f39 100644
> --- a/src/jrd/req.h
> +++ b/src/jrd/req.h
> @@ -161,8 +161,11 @@ public:
> const Format* rec_fmt_bk; // backup format to cope with
> Borland's ill null signaling
> UCHAR rec_flags; // misc record flags
> RecordNumber rec_number; // original record_param number - used
> for undoing multiple updates
> - double rec_dummy; // this is to force next field to a
> double boundary
> - UCHAR rec_data[1]; // THIS VARIABLE MUST BE ALIGNED ON A
> DOUBLE BOUNDARY
> + union
> + {
> + double rec_dummy; // this is to force next field to a
> double boundary
> + UCHAR rec_data[1]; // THIS VARIABLE MUST BE ALIGNED ON A
> DOUBLE BOUNDARY
> + };
> };
>
> // rec_flags
> ----------------
Definitely OK for gcc.
There were some issues with some compiler (found by SAS) with unnamed
unions. Unfortunately I do not remember details, but in that place we
were fighting with unnamed union. On the other hand, anonymous union is
C++ standard, therefore I'd say 'do it'.
> Also look in ProcedureScan.cpp on the usage of irsb_message.
>
> The VaryingString could be replaced by a UCHAR[], and since the memory
> is dynamic allocated, it must be surely aligned even for doubles (then
> not needing to add FB_ALIGNMENT).
Just don't forget to keep length somewhere.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
