Re: structure and constant memebers

On 17 Oct 2005 19:36:13 -0700, Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx>
wrote:

> Dave Thompson <david.thompson1@xxxxxxxxxxxxxxxx> writes:
>
> > On 05 Oct 2005 07:31:56 -0700, Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx>
<snip>
> > > *(int*) ((char*)v + offsetof(struct thing, b)) = b;
<snip>
> > There's no need for v and offsetof; &r->b and (int*)&r->b are fine.
>
> Yes, good point. The truth is, I just forgot about these, because my
> own development practices are so strongly predisposed to never
> "casting away" const-ness.
>
> Incidentally, why did you say "&r->b and (int*)&r->b"? Only
> one expression (the second one) would be used.
>
Well, the latter includes the former so you're using both. <G> I have
a bias toward generalizing or noting related cases so as to avoid
implication that because I omitted something it isn't covered or isn't
the same, especially with my delay in reading and replying to news.
But I agree the latter is the one whose validity is (more) important.

>
> > > Some people might squawk about the '(int*)' cast; they might want to
> > > use
> > >
> > No one should object to the cast as such, which is clearly a pointer
> > (value) to a correctly allocated and aligned object. What some might
> > object to is storing through that pointer, on the grounds the lvalue
> > being used is not suitable for the actual object, although I believe
> > in this case the "untypedness" of malloc-ed space saves us.
>
> I believe no reasonable person would object either to the '(int *)'
> cast or to storing through the resultant pointer value. I put in
> the alternative only to avoid an irrelevant tangential discussion
> about the possible legalities or non-legalities. Not that such
> nitpicking would ever occur in comp.lang.c.
>
I think both objections are wrong, but distinguishable. The pointer
(value) cast is to my reading clearly allowed by direct positive
wording; I don't see _any_ counterargument. The store on its face
triggers the rules about storing into objects and particularly const
objects. In practice the fact that malloc space must be contiguous and
most of it writable means that an implementation couldn't enforce
constness of a subobject in it, and I _think_ the formal reflection of
this should be read to formally affirm it, but I can see that a
counterargument _could_ be made.

<snip: or memcpy>
> > Ditto, except (anynonconst*)&r->b is sufficient to pass to void* ,
> > and void* specifically might be considered good documentation.
> > Yes, this should squash the "wrong type for object" objection.
>
> Legally, you're right.
>
> Stylistically, writing '(void*) &r->b' fails my "what reaction would I
> expect during code review?" test. It works, but for reasons that are
> deceptive or at best obscure. An alternative that might be better:
>
I'm not sure about that. Semantically, I need to pass to memcpy a
pointer to the memory as nonconst but I don't otherwise care _here_
about the type. I think void* expresses that reasonably, and so does
char*. And so does int*, except it does care about the type. If there
were a shop or project style applicable to this I would conform, but I
don't see anything a priori bad about any of these.

> #define dangerous_memcpy(d,s,n) (memcpy( (void*)(d), (s), (n) ))
>
That's certainly an option, although I would probably go with a macro
only if this situation occurs more than a few times in the code --
which I hope it doesn't.

- David.Thompson1 at worldnet.att.net
.

Relevant Pages