der Mouse wrote:
> This feels
> a lot like pushback against my proposal, but nobody has actually come
> right out and said "no, I don't like this", much less "...and here's
> why".

Proposals to change RFC-defined interfaces rarely meet with immediate
universal acclamation.  ;-)

I just see a discussion about what the interface requirements are, and
what may reasonably be demanded of the user.  I think you'd agree,
assuming it can be made to work, that iterating over a series of pointers
is preferable to grabbing chunks of data at offsets.  

> It really seems to me that we should make it as easy as feasible to
> help people write clean code, and playing fast and loose with pointer
> puns in buffers passed through interfaces that don't document alignment
> requirements doesn't qualify.

Well said.  

> Am I correct in inferring that people really don't like the idea of
> making the interface easy to use correctly, preferring to require
> application authors to be sufficiently C-wizardly to (a) realize that
> the current macros demand aligned buffers and (b) either come up with a
> way to arrange that, or bite the bullet and arrange to use malloc?

How easy the interface is to use is a function of how C-wizardly the user
need be.  I'm not sure there's agreement on that point yet.  

> In message <200702122342.SAA01359@Sparkle.Rodents.Montreal.QC.CA>, der
> Mouse writes:
> >> Then use intmax_t instead.  intmax_t is defined as holding the
> >> largest integral value and will be able to contain a pointer as well.
> 
> >Will be able to contain a pointer, sure.  But not necessarily, will be
> >at least as strictly aligned as a pointer.
> 
> To be maximally picky:
> 
> intmax_t can hold a pointer *if any integral type can*.
> 
> I can't imagine us ever porting to a system where that assumption
> wouldn't hold, but it should be pointed out that it IS an assumption.

Do you think that assumption is acceptable?  Would documenting and relying
on intmax_t alignment suffice?  

--jkl