Gabriel Dos Reis wrote:
| However, in order not to mix different issues, I think we should try
| first to resolve the much more limited issue at hand, which, I note,
| has to do with *deallocation*, not with *allocation*.
By the time we deallocate, any possible damage has already be done :-)
So, yes, you can add the casts as a temporary work-around.
Ok.
We still would not have solved the issue (I do not believe we have
separate issues).
Well, the issue with max_size vs size vs difference_type certainly we
don't have anywhere, besides my private emails with Howard ;) Certainly
I want to tackle it but I'm not sure whether is purely an implementation
(v3) issue: I don't think the standard is very clear about the value of
max_size.
About v3, note that currently, similarly to other implementations I
think, in v3 container::max_size does *not* return a value directly, but
essentially forwards to allocator::max_size. In general, I think the
allocator should be definitely involved, because it can well decide to
return sizes much smaller than numeric_limits<size_type>::max_size /
sizeof(T).
In summary, for v3, one possibility could be combining the two
quantities, consistently for all the containers, thus, essentially,
compute container::max_size as min(allocator::max_size,
numeric_limits<difference_type>::max) (all the computations modulo
sizeof(T)). In this way, we could be sure that, in vector for example,
substracting the _M_start and _M_finish pointers doesn't overflow a
ptrdiff_t (the latter finally is casted to a size_t in order to call
allocator::deallocate). Do you agree with opening a separare v3 PR and
tackling it along this route?
Paolo.
