Xref: news-dnh.mv.net comp.os.msdos.djgpp:709
Path: news-dnh.mv.net!mv!news.sprintlink.net!demon!chocolat.demon.co.uk!PS
From: Paul Shirley <PS AT chocolat DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Size of a.out
Date: Thu, 29 Jun 95 02:46:34 GMT
Organization: a loose end.
Lines: 23
References: <DAw7zG DOT Axw AT jade DOT mv DOT net>
Reply-To: PS AT chocolat DOT demon DOT co DOT uk
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk "A.Appleyard" writes:

)C++ program             A.OUT size unstripped    A.OUT size stripped
)int x[10000]; main(){}  52269                    44140
)main(){}                15387                     7276
)   (difference)         36882                    36864
)
)  Why does declaring the array `x' add so much size to A.OUT? Surely there is
)a more compact way of telling the loader to set the next 40000 bytes of RAM to
)all zeros, than to write out 40000 zeros at length in the .EXE file? Long ago
)in the CDC7600 mainframe's equivalent of .EXE files, there was a special
)compact notation for "repeat the next n bytes p times". Why not in PC's? (I
)know that the A.OUT from `int x[10000]; main(){}' contains 40000 consecutive
)ascii-zeros that aren't in the A.OUT from `main(){}': I just looked!)

Use the -fconserve-flag, and it magically goes away! (should work if
added to your SPECS file as well). This really should default to enabled
although maybe that breaks something?


-- 
Paul Shirley: SemiProfessional Coffee & Chocolate Taster