Date: Fri, 16 Nov 2012 00:09:23 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: Mateusz Guzik <mjguzik@gmail.com>, avg@freebsd.org, freebsd-current@freebsd.org Subject: Re: compiler info in kernel identification string Message-ID: <50A57623.4020108@FreeBSD.org> In-Reply-To: <1352907497.1217.147.camel@revolution.hippie.lan> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-11-14 16:38, Ian Lepore wrote: > On Wed, 2012-11-14 at 10:25 +0100, Dimitry Andric wrote: ... >> That way, you are sure never to lose information. This also works for >> gcc from ports (which is the reason for the space after 'version' in the >> grep command): >> >> $ gcc47 -v 2>&1 | grep 'version ' >> gcc version 4.7.3 20120929 (prerelease) (FreeBSD Ports Collection) >> >> I realize this is a bit long, but it is better to have complete than >> stripped information. > > Rather than just taking whatever the compiler emits, the proposed patch > seems to be carefully crafted to avoid breaking existing 3rd party tools > which parse uname output based on the location of whitespace. I'm not > sure how important that is given that the uname manpage doesn't document > the output format as if it were somehow rigidly specified. I can see where you're coming from, but I also think it is very fragile to depend on parsing such information from uname. If you do so, you must be prepared to accept wonky input, otherwise, just don't do it. :) And as I remarked in another reply, now that I have thought about it a bit, I would much rather see this information moved to a sysctl or dmesg line, than in uname. With the happy side effect that no existing uname parsers would be confused!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A57623.4020108>