> "Enrico" == Enrico Migliore <[EMAIL PROTECTED]> writes:
Enrico> Since we got GNU libc code, my suggestion is, for each
Enrico> architecture, compile _ALL_ the C code with the same set of C
Enrico> flags, including the libc.
Enrico> In this way, the libc and the VM will be a monolithic
Enric
Why would people want to recompile libc?
geir
On Oct 7, 2005, at 12:16 PM, Dan Lydick wrote:
It seems that not all versions of 'libc' are compiled
with the same flags. Furthermore, the edition that I
am using (GCC 3.3.3 on Solaris 9) apparently does not
use all the same flags all the way a
L PROTECTED]>
To:
Date: 10/7/05 2:12:05 AM
Subject: Re: opinions on structure packing in C?
I'm working with Dan's bootVM to get to run on Windows, and have
been
thinking about the use of -fpack-struct vs #pragm pack() vs just not
packing and writing code that is a little slower,
libc' question on the table because
surely other people are going to run into it when
they look at the code and try compiling.
Dan Lydick
> [Original Message]
> From: Enrico Migliore <[EMAIL PROTECTED]>
> To:
> Date: 10/7/05 2:12:05 AM
> Subject: Re: opinions on stru
I'm working with Dan's bootVM to get to run on Windows, and have been
thinking about the use of -fpack-struct vs #pragm pack() vs just not
packing and writing code that is a little slower, and a little more
verbose, but seemingly more robust and maintainable due to less
information about
On Oct 5, 2005, at 9:04 AM, Robin Garner wrote:
So how do people deal with this these days? I know fashions change,
and I haven't done C in anger for > 6 years... (I still have the
shakes when looking at it - I'm past the screaming stage...)
"Premature optimization is the root of all ev
On Oct 5, 2005, at 9:44 AM, Tim Ellison wrote:
Geir Magnusson Jr. wrote:
I'm working with Dan's bootVM to get to run on Windows, and have been
thinking about the use of -fpack-struct vs #pragm pack() vs just not
packing and writing code that is a little slower, and a little more
I'd disput
> "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes:
Dan> It has been my experience that permitting structures to remain
Dan> _unpacked_ produces compatibility problems.
Dan> My use of GCC 3.3.2 on Solaris 9 seemed to confirm
Dan> this when all library and system calls worked fine
Dan> except fo
> [Original Message]
> From: Tim Ellison <[EMAIL PROTECTED]>
> To:
> Date: 10/5/05 8:45:23 AM
> Subject: Re: opinions on structure packing in C?
>
> Geir Magnusson Jr. wrote:
> > I'm working with Dan's bootVM to get to run on Windows, and have been
Robin Garner wrote:
So how do people deal with this these days? I know fashions change,
and I haven't done C in anger for > 6 years... (I still have the
shakes when looking at it - I'm past the screaming stage...)
"Premature optimization is the root of all evil."
Agreed.. it's way too earl
Geir Magnusson Jr. wrote:
> I'm working with Dan's bootVM to get to run on Windows, and have been
> thinking about the use of -fpack-struct vs #pragm pack() vs just not
> packing and writing code that is a little slower, and a little more
I'd dispute that packing always produces faster code, bu
> So how do people deal with this these days? I know fashions change,
> and I haven't done C in anger for > 6 years... (I still have the
> shakes when looking at it - I'm past the screaming stage...)
"Premature optimization is the root of all evil."
If struct packing produces a measurable spee
I'm working with Dan's bootVM to get to run on Windows, and have been
thinking about the use of -fpack-struct vs #pragm pack() vs just not
packing and writing code that is a little slower, and a little more
verbose, but seemingly more robust and maintainable due to less
information about co
13 matches
Mail list logo
