>
> Unless the on disk format is carried over into memory, there's no
> reason not to use a structure alignment which prevents unaligned
> access.
>
> I'm a little surprised your compiler hadn't already padded the struct
> out to proper alignment when you built SQLite.
>
Sorry, I'm a little bit
On 3/27/06, Alexei Alexandrov <[EMAIL PROTECTED]> wrote:
> >
> > Isn't this eliminated with the proper compile settings for data packing?
> > There should be a compile option for sometihng like 'align data on N
> > byte boundaries'
> >
>
> Even if that is possible, I don't want to say to compiler
>
> Isn't this eliminated with the proper compile settings for data packing?
> There should be a compile option for sometihng like 'align data on N
> byte boundaries'
>
Even if that is possible, I don't want to say to compiler "Please
align everything on 16 bytes" because this will lead to huge
On 3/25/06, Alexei Alexandrov <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I don't know whether it's been already reported or not, so anyway.
> There are places in SQLite where unaligned access exception is
> generated on Itanium. The unaligned access means that someone tries to
> read or write memory
"Alexei Alexandrov" <[EMAIL PROTECTED]> wrote:
> >
> > Well, it's supported by most compilers today, but I try to avoid
> > anonymous unions in C code as well. They are fairly standard for C++,
> > but not for C. But the approach seems fine to me - the alignment will
> > be forced in this case.
>
>
> Well, it's supported by most compilers today, but I try to avoid
> anonymous unions in C code as well. They are fairly standard for C++,
> but not for C. But the approach seems fine to me - the alignment will
> be forced in this case.
>
Just to make it clear: can I expect this fix in the next
> Perhaps a better fix is this:
>
> struct Mem {
>i64 i;
>double r;
>char *z;
>int n;
>u16 flags;
>u8 type;
>u8 enc;
>void (*xDel)(void *);
>union {
> long double notUsed1;
> char zShort[NBFS];
>};
> };
>
> The compiler would then (hopefully)
"Alexei Alexandrov" <[EMAIL PROTECTED]> wrote:
> >
> > Perhaps the following definition of Mem would work better:
> >
> > struct Mem {
> >u16 flags;
> >u8 type;
> >u8 enc;
> >char *z;
> >int n;
> >i64 i;
> >double r;
> >char zShort[NBFS];
> >void (*xDel)(void
"Alexei Alexandrov" <[EMAIL PROTECTED]> wrote:
> As far as I understand, this fix will take the problem away only
> because SumCtx is bigger now. But the problem with
> sqlite3_aggregate_context will remain: the pointer returned will not
> be aligned properly if the size of the context is less or
As far as I understand, this fix will take the problem away only
because SumCtx is bigger now. But the problem with
sqlite3_aggregate_context will remain: the pointer returned will not
be aligned properly if the size of the context is less or equal 32
bytes. Am I correct?
On 3/25/06, [EMAIL
"Alexei Alexandrov" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I don't know whether it's been already reported or not, so anyway.
> There are places in SQLite where unaligned access exception is
> generated on Itanium. The unaligned access means that someone tries to
> read or write memory crossing
Hi,
I don't know whether it's been already reported or not, so anyway.
There are places in SQLite where unaligned access exception is
generated on Itanium. The unaligned access means that someone tries to
read or write memory crossing 8-bytes boundary. Usually this occur as
a result of pointers
12 matches
Mail list logo