svn commit: r274340 - in head/sys: crypto/rijndael dev/random geom/bde

[Brooks Davis]

On Tue, Nov 11, 2014 at 03:07:54PM +0100, Dag-Erling Sm?rgrav wrote:
> Bruce Evans <brde at optusnet.com.au> writes:
> > -Wcast-qual is not a very good warning option since the official way
> > to remove qualifiers in C is to cast them away.  Casting them away is
> > better than using the __DECONST() abomination.  The option exists
> > because it is too easy for sloppy code to cast away const without
> > really intending to or when casting away const is done intentionally
> > but is an error.
> 
> I agree that __DECONST() is ugly (not least because it strips all
> qualifiers, not just const, so it should be DEQUAL()), but the
> alternative is worse.  In my experience, the majority of cases where a
> cast discards a qualifier are bugs, with struct iov being one of very
> few legitimate use cases.

On the processor we (SRI and Cambridge) are working on, pointers
are not integers (we support some integer behaviors, but not
pointer->int->pointer casts except in limited cases) and the current
__DECONST implementation will need to die[0].  For existing C versions
some sort of compiler support for __DECONST is probably the right thing
to do.  In general, we need to fix the C/C++ standard to us express the
things we actually mean when we use const (for example see strchr()'s
use of const).  I believe the last issue now being tracked on Google's
internal list of deficiencies in the C++ standard.

-- Brooks

[0] The recently discussed _ALIGN also needs to die and be replaced with
something that increments the pointer (or returns how much to increment)
rather than jamming it though a long.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20141111/af2fe0c4/attachment.sig>