From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | lt660(at)ipisun(dot)jpte(dot)hu (Tamas Laufer) |
Cc: | hackers(at)postgresql(dot)org (PostgreSQL-development) |
Subject: | Re: [BUGS] Some BUG-FIXES to postgreSQL on SCO 3.2v5.0.2 |
Date: | 1998-01-11 20:45:23 |
Message-ID: | 199801112045.PAA08749@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Applied with #if defined(sco) for 6.3. Beta testing Feb 1.
>
> You wrote:
>
> > > 2.) For the float8, it's required to edit the file
> > >
> > > ./src/include/utils/memutils.h
> > >
> > > #define DOUBLEALIGN(LEN) INTALIGN(LEN)
> > > #define MAXALIGN(LEN) INTALIGN(LEN)
> > >
> > > Otherwise the backend will crash at the insertion of any float8.
> >
> > I am unsure why the existing code did not work.
>
> Sorry, I am sure. Let me try to convince you.
>
> I must quote the HTML version of the manual entitled as
> "Programming Tools Guide Appendix A, ANSI implementation-defined
> behavior".
>
> ****<Beginning of partial partial citation>
>
> This section describes the implementation-defined characteristics of
> structures, unions, enumerations, and bit-fields. It corresponds to
> section ``F.3.9 Structures, Unions, Enumerations, and Bit-Fields'' in
> the ANSI document.
> ........
> 80x86 does not impose a restriction on the alignment of objects;
> any object can start at any address. However, for certain objects,
> having a particular starting address can speed up processor access.
>
> The C compiler aligns the whole structure on a 4-byte boundary by
> default (see ``Pragmas''). All [4|8|10]-byte objects are aligned on a
> 4-byte boundary, 2-byte objects are aligned on a 2-byte boundary, while
> 1-byte objects are not aligned.
>
> ****<End of citation>
>
> Now, it's clear: the *double* struct members will be aligned to a
> *4-byte* address boundary (on SCO), but *the original code* computes
> "DOUBLEALIGN" and "MAXALIGN" to a
> *8-byte boundary*, because it defines the boundary of alignment as
> *sizeof(double)* which is equal to 8 (on SCO).
> This may lead to the "segmentation violation error",
> which is only the consequence of a correct malloc (palloc) executed
> after the corruption of administrative areas of malloc caused by
> erroneous access of double struct members. (I have traced it.)
>
> Let me make some possibly unneccesary comments:
> This type of assumptions is very "popular" in sytems originally
> developed on other (BSD-derived or RISC-based) sytems.
> The most popular form is the assumption about the behaviour of *malloc*:
> it will align an malloc(sizeof(something)) to a *8-byte boundary*.
> But it isn't the case.
> Fortunately the postgreSQL not uses this assumption which holds
> for your reference platform too.
>
>
> Regards,
> Tamas
> _________________________________________
> Tamas Laufer
> Voice/Fax: +36-72-447-570
> Email: lt660(at)ipisun(dot)jpte(dot)hu
> H-7632 Pecs, Fulep L. u 26 III/11 Hungary
>
--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-01-11 20:45:54 | Re: [HACKERS] Re: [BUGS] Some BUG-FIXES to postgreSQL on SCO 3.2v5.0.2 |
Previous Message | Bruce Momjian | 1998-01-11 20:37:21 | Re: [HACKERS] Small? things to fix... |