Date: Fri, 7 Dec 2007 20:39:24 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: src-committers@freebsd.org, Kip Macy <kmacy@freebsd.org>, Kip Macy <kip.macy@gmail.com>, cvs-all@freebsd.org, Bruce Evans <brde@optusnet.com.au>, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/sys param.h Message-ID: <20071207202906.N1272@besplex.bde.org> In-Reply-To: <475875AE.6040900@gmx.de> References: <200712060400.lB640xxi025146@repoman.freebsd.org> <20071206202639.N11122@delplex.bde.org> <b1fa29170712061104i5cd14280t7033bca039bec3ff@mail.gmail.com> <475875AE.6040900@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Dec 2007, Christoph Mallon wrote: > Kip Macy wrote: >> On Dec 6, 2007 2:25 AM, Bruce Evans <brde@optusnet.com.au> wrote: >>> On Thu, 6 Dec 2007, Kip Macy wrote: >>> >>>> kmacy 2007-12-06 04:00:59 UTC >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: >>>> sys/sys param.h >>>> Log: >>>> Respect the fact that the value a may be constant so cast to const >>>> uint8_t * >>>> >>>> Revision Changes Path >>>> 1.318 +2 -2 src/sys/sys/param.h >>> The correct fix is to back out 1.317. If not, at least spell `unsigned >>> char' correctly and fix the other new style bug (a line longer than >>> 80 characters from adding `const'). Using uint8_t is only a style bug >>> since POSIX probably requires unsigned char to be the same as uint8_t. >>> If unsigned char is larger than uint8_t, then revs.1.317-318 give >>> undefined behaviour (aliasing bugs) and clearly broken behaviour (wrong >>> divisor NBBY). These bugs are easy to avoid by using the correct >>> spelling. >> >> I'm inclined to do whatever you say so long as my code works without a >> substantial rewrite. Couldn't you just use a cast in your own code. Code newer than 1994 should probably use bitstring(3). 4.4BSD put bitstring.h in src/include 1994, and FreeBSD repo-copied bitstring.h to src/sys/sys in 2003. > However, can you please point me at where it says >> uint8_t is not style(9) compliant? > > I think, he means that uint8_t is not necessarily the same type as unsigned > char. In fact according to the C99 standard the type uint8_t does not > necessarily exist (section 7.18.1.1). Right. I checked that POSIX.1.2001 explicitly requires uint8_t and other fixed-width types to exist (mainly because POSIX finally got around to Standardizing 20-year old mistakes in network APIs -- (in_addr_t is uint32_t, etc.)), and that when uint8_t exists, C99 implicitly requires unsigned char to have the same representation as unsigned char (because unsigned char is the smallest non-bitfield type, and uint8_t is as small as possible -- both must be 8 bits with no padding). The remaining details are subtler -- does having the same representation require the types to be the same in this case though it doesn't in general, or is having the same representation enough for the special features of unsigned char to apply to uint8_t? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071207202906.N1272>