begin quoting Carl Lowenstein as of Fri, Jul 18, 2008 at 09:11:54PM -0700: > On Fri, Jul 18, 2008 at 8:44 PM, James G. Sack (jim) <[EMAIL PROTECTED]> > wrote: > > Carl Lowenstein wrote: > >> > >> If I may allude to an old discussion, isn't this an argument for > >> embedding people-readable tags in object files? > > > > I only kinda-vaguely recall that discussion. What was the context and > > conclusion -- do you remember? > > > > In any case, I can think of something else to observe: embedded labels > > can not really be used to verify files -- you need a real hash > > authentication mechanism to do that, eh? But that wasn't the question > > here, I don't think ..so.. nevermind. :-) > > It started with my observation that gcc now optimized away strings > that were never used. Said strings were to be embedded in object > files as a record of RCS ID or equivalent. > > On the kplug-lpsg list with subject: "gcc optimizes out program ID > string" and much rancor. > > The accepted answer is that the previous behavior of gcc has been > deprecated for some time, and there is now > __attribute__((unused)) > to deal with cases like this.
I no longer trust GCC's idea of "deprecation" -- they deprecated the Objective-C "import" syntax because they didn't like it, and wanted to discourage its use. I liked the scheme where there was actually a code-path that referenced every human-readable-embedded-string. That got a bit complicated, 'tis true, but it has the wonderful advantage of no longer requiring the user to run another utility to inspect the executable file. Plus, __attribute__((unused)) is ugly. -- And is that even portable between C compiler implementations? Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
