cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c

[Poul-Henning Kamp]

In message <1058974459.31173.17.camel at localhost>, Paul Richards writes:
>On Wed, 2003-07-23 at 06:40, Poul-Henning Kamp wrote:
>
>> 
>> The ones I took out yesterday are the onces which GCC had ignored and
>> which therefore ipso facto were "unproven" _and_ added significant
>> amounts of object code if respected. 
>
>That's just untrue. The inline you removed from lnc had *ZERO* impact on
>code size.

It would _really_ help if you would bother to listen to what people
tell you about how the new GCC warnings work.

GCC rejects inlining things above a certain limit, and while the
limit is arguably measured in "elbonian mud gallons", it is nontheless
something we have to address: If we ever want to be able to use
those warnings to tell us when something is amiss, we need to set
the limit reasonably.

The two inlines in the lnc driver were among the largest in the
system.  If we had set the GCC limit to allow those inlines, we
would never get a warning when inline mistakes were made.

And when you consider that that the inlines in lnc were purely
ornamental, and that GCC previously had silently refused the
inline request, you will realize that by removing them, I merely
preserved the status-quo.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.