Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: Adding Blank Line In Source Causes Change In Executable Date: Tue, 6 Mar 2012 19:51:17 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 25 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-03-009@comp.compilers> References: <12-03-007@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1331069546 31309 64.57.183.58 (6 Mar 2012 21:32:26 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Tue, 6 Mar 2012 21:32:26 +0000 (UTC) Keywords: code, practice Posted-Date: 06 Mar 2012 16:32:26 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:476 Morris, John M CIV NSWCDD, Q34 wrote: (snip) > I am not intentionally including debug information in my builds. Some compilers may generate debugging by default. Others may not even have an option to turn it off. On many systems, a link-time option is needed to put the compiler generated debugging data into the executable, but maybe not all. > I assumed that blank lines in the source would have no impact on > the executable, but that appears to be incorrect. A common debugging feature allows for the printing of statement numbers in error messages, which means that they have to get into the executable. The usual optional debugging information, for example -g in GNU compilers, allows variable names to be included for debugging. Variable names tend to take up a lot more room than just statement numbers. Including source statement numbers does not necessarily follow the same debugging option, and may even not be optional. -- glen