RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it

[Eric Weddington]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, February 13, 2007 2:28 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call 
> main ratherthanjumping to it
> 
> As Anatoly Sokolov wrote:
> 
> > I would prefer to correspond to 'C' standard completely, but we are
> > ready to pay such price, for that that function 'main()' to be
> > callable?
> 
> That's I would like to have that as a command-line option.  We
> definately should adhere to the C standard by default, but by
> suggesting the users to use an option like -momit-mainframe (:-), they
> can adjust it to the current behaviour.  Documentation needs to
> clarify the implications of using that option.
> 
> As for suggesting that to the users, I think the Makefile templates
> (WinAVR, Mfile, AVR Studio Makefile generation) are already doing a
> good enough job, so many users probably wouldn't notice it at all.

I'm sorry, could you clarify this? Are you suggesting that we will have to
*add* a command-line option to get the smaller code? If so, this certainly
doesn't help backwards-compatibility.

 
> So far, I've seen a couple of users (maybe) complaining on
> avrfreaks.net, not more, and in that case, it's already been the
> pathological case you've been quoting.
> 
> Of course, if the command-line option is impossible for some reason
> (e.g. since it would make the RTL too complicated or whatever), we
> really have to see whether standards conformance or code bloat is more
> important for us.

I like the ideal of standards conformance, but the bottom line is that I
lean towards practicality and no code bloat.

I would also prefer NOT adding a new command-line option to get the older
smaller code. This induces versioning issues to achieve the same
functionality.

Eric