Re: proposal: some pointer and arithmetic utilities

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> [...], if the application structure you are designing needs one of
> these overhead structures you'll just make life simple by placing it
> at the very top of the application structure.  This means the extra
> pointer you are asking the library to make additional space to store
> will, if cast to the overhead structure type, be bit-for-bit
> identical to the pointer to the overhead structure.

Not necessarily.  It will point to the same object, but I don't think
there's any guarantee that two pointers to the same object are always
bit-for-bit identical.  If nothing else, there may be padding bits.
(At least, I'm fairly sure that's true of C.  Does POSIX contain such a
promise?)

This "place it at the top of the sturct" paradigm strikes me as bad
interface design.  If nothing else, it makes it impossible to have two
such library structs in the same application struct.  It also makes it
impossible for the library struct to be opaque to the application code;
it can be undocumented, but it can't be opaque.  It also means that
modifying the library struct introduces nontrivial ABI issues.

None of these problems arise when the library struct is entirely
private to the library, with its caller treating it either as void * or
as a pointer to an incomplete struct type - or, in cases where it can
be done, not having anything to do with it at all.  (Well, the last one
potentially arises, but it's a lot easier to deal with.)

> You are asking the library to spend space and instructions to store
> an exact copy of the thing the library is going to be storing
> already,

"Already"?  Only if you insist on the embedded-struct interface design.

> so you're adding cost to the normal case where there is no need to
> spend anything in execution.

No need?  Perhaps...unless you want to be able to use two such library
structs in the same application struct.  Or unless you want compiler
help enforcing opacity of the library's private data.  Or unless you
want a future-ready ABI.

> If there's something that needs to be fixed here I'd prefer it not to
> add execution cost, in either space or instructions, to the normal
> case,

I'd prefer that too.

I'm not convinced it's possible.  (I'm even less convinced it's
possible to do without making nonportable assumptions about the way the
compiler implements certain things.)

> So I'm getting the impression that the cost is supposed to buy
> "safety", but I don't see how.  The fundamental problem is that, for
> certain types of functions written in C, the goals of producing
> reusable code, so one implementation can be shared by every
> application which needs that service, and type safety, so that the
> compiler helps identify misuses, seem to be mutually exclusive.

Yes.  C does not have real polymorphism, so it is not possible for
polymorphic interfaces in C to be type-correct.  Hence, of course, both
your example interfaces have type-safety risks.

I don't know what was in the minds of the people who wrote the emails
you got your impression from.  But I do see reasons - sketched above -
to prefer the first kind of interface.

> I hence get what container_of() seems to be good for.

I like it about as much as I like offsetof - which is to say, I think
it is a mistake.  I have trouble imagining a use for it that is neither
premature optimization nor so heavily in need of "every last cycle"
optimization that it arguably shouldn't be in C at all.  There might be
a place for it in implementing heavily MD features; IMO that value is
outweighed by the misleading cachet having it as available as has been
outlined upthread would give it.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B