Date: Tue, 25 Sep 2012 18:14:05 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r240773 - in head/sys: amd64/amd64 i386/i386 Message-ID: <5061D84D.4020400@FreeBSD.org> In-Reply-To: <201209250807.46163.jhb@freebsd.org> References: <201209211031.q8LAVKVC014601@svn.freebsd.org> <201209250807.46163.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-09-25 14:07, John Baldwin wrote: > On Friday, September 21, 2012 6:31:20 am Dimitry Andric wrote: >> Author: dim >> Date: Fri Sep 21 10:31:19 2012 >> New Revision: 240773 >> URL: http://svn.freebsd.org/changeset/base/240773 >> >> Log: >> After r205013, amd64 and i386 CPU family and model IDs were printed out >> in hexadecimal, but without any 0x prefix, which can be very misleading. >> >> MFC after: 3 days > > This overflows 80 columns now where it did not before. Ehm, most of dmesg lines overflow 80 columns; in fact, the lines just below this print the CPU feature bits, which are easily a few wrapped lines long. So I don't really see the point in obfuscating those numbers. Are we interested more in "beautifying", than giving unambiguous information? > Intel manuals tend > to use a trailing 'h' suffix rather than an '0x' prefix. (It is common to > see text like '06_2Ah'.) The prefix was previously left off on purpose due to > the 80 colummns overflow. I think that was a mistake, if something is hexadecimal, it should be clearly indicated, otherwise it is extremely confusing. Intel assembly is basically the only variant still out there using the 'h' suffix, the rest of the (C) world uses 0x. :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5061D84D.4020400>