-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/03/11 01:51, Jakub Jelinek wrote:
> Hi!
>
> On Wed, Nov 02, 2011 at 09:28:52PM -0600, Jeff Law wrote:
>> This was caught by some prototype code to warn for potential
>> NULL pointer dereferences.
>
> Clearly we have a set of vec.h operations that require the vector
> to be non-NULL.
Yea, most of them :-)
> Seems it is last, index (which already have such check in their
> VEC_ASSERT), then the 7 ops you've changed, embedded_init which I
> think you've missed and splice which you've changed which requires
> dst to be non-NULL, but src may be NULL. For checking builds I'd
> say it is ok to add those to the VEC_ASSERT,
embedded_init should check, I missed that completely as I was
searching for missing checks within the existing VEC_ASSERTs. I'll
add that to the patch.
but don't we have to do anything about the non-ENABLE_CHECKING
> case? We will still have code like:
> (VEC_rtx_base_replace(((reg_base_value) ? &(reg_base_value)->base :
> 0),(rhs_regno(reg1)),((rhs_regno(reg2)) <
> (VEC_rtx_base_length(((reg_base_value) ? &(reg_base_value)->base :
> 0))) ? (VEC_rtx_base_index(((reg_base_value) ?
> &(reg_base_value)->base : 0),(rhs_regno(reg2)) )) : 0) )); with
> static __inline__ rtx VEC_rtx_base_replace (VEC_rtx_base * vec_,
> unsigned ix_, rtx obj_) { rtx old_obj_; (void) (vec_ && ix_ <
> vec_->prefix.num); old_obj_ = vec_->vec[ix_]; vec_->vec[ix_] =
> obj_; return old_obj_; }
>
> Shouldn't we for non-ENABLE_CHECKING just call it with
> (&(reg_base_value)->base) instead of ((reg_base_value) ?
> &(reg_base_value)->base : 0) ?
Well, if we're going to go that direction, I'd just say define
VEC_BASE to (&(P)->base) for non-checking rather than mess with the
NONNULL variant. Is there some reason why we don't do that?
In fact, I don't really see what the current VEC_BASE definition buys
us, I briefly toyed with the idea of defining it like
#define VEC_BASE(P) ((P) ? &(P)->base : vec_assert_fail ...)
But I don't know the VEC code at all and it hurts my head every time I
look at it, so I didn't push the envelope beyond what was clearly an
improvement.
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOsr+iAAoJEBRtltQi2kC7ny4H/3VWwriXn2f/vxr2A4a0Ix2B
RvoiVZAzUqn/3ubni4rJuyc4Z0eQDcQZk3N+EVHeC73En2HIZ4B4vgGUAaM0YEGV
SQSZded0U2Riq3R/+DtT6VGiuafngDB3/VqIqu5zn2scz9cqHMb5jl05TIrT+fZw
8bLfvifzJFoaak6x+E85jF1ooS1/aUsHCmonq9Y4PX3FgOv2DmIEme6oV1Sqer4Z
oEGtm4rCO35OQD8cG0EFrBfiHZuTTNQcaUMtQpmV61seNSyd2ggrvfjTCq2JE6Zg
69WwgYPv3+J7+Zz310VZT1O7Rh/HwUhmFUsySSGSviaLSdqiFkFuLKA8fLWLgzE=
=UKL7
-----END PGP SIGNATURE-----
