This discussion is probably useless.  :)

In article <20020915170644.H505@dr-evil.shagadelic.org>
thorpej@wasabisystems.com writes:

> On Mon, Sep 16, 2002 at 08:50:35AM +0900, ITOH Yasufumi wrote:
>  > If a program is only tested on ELF toolchain, the quality of code
>  > is like this.
> 
> Eh.  While I do believe you that the different object format exposed these
> bugs, I'm not sure a blanket statement like "quality of code is like this"
> is really fair nor accurate.  It's like saying we should all use Alphas
> instead of x86 systems so that finding unaligned access bugs is easier.

Yeah, but I'm under impression that
  ``This program is developed in a.out, and just works for other formats''
is more probable than that
  ``This program is developed in ELF, and just works for other formats''
where the program is supposed to be a portable C program.

I said this as quality.

>  > ELF has other too unique features (ex. C symbols and assembler symbols
>  > are same, dynamic linker automatically loads dependent libraries),
>  > which make it easy to write non-portable programs.
> 
> Err... There are lots of other things that make it easy to write non-portable
> programs, too.  Should we remove the err(3)/warn(3) family of functions from
> our C library?

Oops, I didn't mean portability between platforms.
I mean possibility that a program ``just works'' on
different binary formats on a platform.

> In what way is a.out doing things differently than ELF in the examples
> you cited above?  Not issuing .align directives, or something?

I haven't confirmed, but probably
ELF places static data using larger zero-filled alignment,
while a.out places them using smaller alignment.
-- 
ITOH Yasufumi