Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
[Falk Hueffner] > First, IMHO we should drop this stuff and just use malloc. I don't > see any point in increasing code size and introducing new bugs > thereby. I agree too. Unless there is a very good reason to keep it, we should remove the allocator code and use malloc() instead. Someone need to provide patches, and test the new version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
sön 2003-10-12 klockan 23.48 skrev Falk Hueffner: > First, IMHO we should drop this stuff and just use malloc. I don't see > any point in increasing code size and introducing new bugs thereby. I agree. I don't see why this is necessary. Sure, malloc is slow if you need zillions of small allocations all the time, but I don't see the importance of speed in an installer. Code size and correctness are far more important. /Martin -- Martin Sjögren [EMAIL PROTECTED] -- [EMAIL PROTECTED] GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html let hello = "hello" : hello in putStr (unlines hello) signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
Richard Hirst <[EMAIL PROTECTED]> writes: > On Sun, Oct 12, 2003 at 11:48:07PM +0200, Falk Hueffner wrote: > > Just use long mem[] there, we can assume a C99 compiler, and it will > > ensure alignment (at least for all Linux platforms). > > Really? I thought the code later referenced something like > > &foo->mem[bar] > > which will surely break if you just s/char/long/ Dunno, might need to add casts there. I would've thought it only casts the value to void*. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
On Sun, Oct 12, 2003 at 11:48:07PM +0200, Falk Hueffner wrote:
> First, IMHO we should drop this stuff and just use malloc. I don't see
> any point in increasing code size and introducing new bugs thereby.
>
> Anyway:
>
> > struct di_mem_area
> > {
> > di_mem_area *next; /**< the next mem area */
> > di_mem_area *prev; /**< the previous mem area */
> > di_ksize_t index;/**< the current index into the "mem" array */
> > di_ksize_t free; /**< the number of free bytes in this mem area */
> > di_ksize_t allocated;/**< the number of atoms allocated from this area */
> > char mem[MEM_AREA_SIZE]; /**< the mem array from which atoms get allocated
> > * the actual size of this array is determined by
> > * the mem chunk "area_size". ANSI says that it
> > * must be declared to be the maximum size it
> > * can possibly be (even though the actual size
> > * may be less).
> > */
> > };
> >
> >
> > I also wonder about MEM_AREA_SIZE being hardwired at 4, although I
> > didn't dig in to the code far enough to see if it should be 8 on 64
> > bit platforms.
>
> Just use long mem[] there, we can assume a C99 compiler, and it will
> ensure alignment (at least for all Linux platforms).
Really? I thought the code later referenced something like
&foo->mem[bar]
which will surely break if you just s/char/long/
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
First, IMHO we should drop this stuff and just use malloc. I don't see
any point in increasing code size and introducing new bugs thereby.
Anyway:
> struct di_mem_area
> {
> di_mem_area *next; /**< the next mem area */
> di_mem_area *prev; /**< the previous mem area */
> di_ksize_t index;/**< the current index into the "mem" array */
> di_ksize_t free; /**< the number of free bytes in this mem area */
> di_ksize_t allocated;/**< the number of atoms allocated from this area */
> char mem[MEM_AREA_SIZE]; /**< the mem array from which atoms get allocated
> * the actual size of this array is determined by
> * the mem chunk "area_size". ANSI says that it
> * must be declared to be the maximum size it
> * can possibly be (even though the actual size
> * may be less).
> */
> };
>
>
> I also wonder about MEM_AREA_SIZE being hardwired at 4, although I
> didn't dig in to the code far enough to see if it should be 8 on 64
> bit platforms.
Just use long mem[] there, we can assume a C99 compiler, and it will
ensure alignment (at least for all Linux platforms).
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
package: libdebian-installer
version: cvs
tags: d-i
di_mem_chunk_alloc() returns 4 byte aligned areas, even on 64 bit
platforms. This is bad, when the caller is going to lay some struct
containing longs or pointers over the alloc-ed memory. On ia64 it
results in loads of unaligned access exceptions flooding dmesg.
Alloc-ed memory comes from the mem[] array in the following struct
(from src/mem.c):
struct di_mem_area
{
di_mem_area *next; /**< the next mem area */
di_mem_area *prev; /**< the previous mem area */
di_ksize_t index;/**< the current index into the "mem" array */
di_ksize_t free; /**< the number of free bytes in this mem area */
di_ksize_t allocated;/**< the number of atoms allocated from this area */
char mem[MEM_AREA_SIZE]; /**< the mem array from which atoms get allocated
* the actual size of this array is determined by
* the mem chunk "area_size". ANSI says that it
* must be declared to be the maximum size it
* can possibly be (even though the actual size
* may be less).
*/
};
given:
include/debian-installer/types.h:typedef uint32_t di_ksize_t
the above array comes out at 4 byte alignment.
We need to make mem[] aligned(MEM_ALIGN).
I also wonder about MEM_AREA_SIZE being hardwired at 4, although I
didn't dig in to the code far enough to see if it should be 8 on 64 bit
platforms.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
