Re: [PATCH] Robust basic_filebuf::imbue

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

I see quite a few rather non-trivial issues here, it will take me a
while to review this, as a single piece of work, be warned. If there are
issues which are really about non-conforming behavior, not QOI should be
dealt with first, by the way, separately, in smaller patches.

A couple of quick comments.
> Also, I changed _M_terminate_output to allocate codecvt::max_length
> bytes for the unshift sequence. This enables block encodings of size >
> 128. Also, it matches the implementation of regular output conversion
> in _M_convert_to_external. (By the way, that is an unbounded alloca in
> _M_convert_to_external; we really should fix that.) The included
> testcase is a block encoding but the block size is only a few bytes.
Are such encodings *really* widespread?
> Finally, the negative return value from _M_get_ext_pos got annoying so I positivized it. Also fixed the return type; matching the "int" from codecvt::length was stupid. Return types don't affect anything in the linker, right?
>   
You positivized :) it but I see a ptrdiff_t as return type, which is
still signed, only wider (on 64-bit machines). There is something I
don't understand here.

Also, I'm seeing typeid uses. Are those *really* unavoidable? We are
keeping the uses of RTTI to the minimum, generally, and most of the
headers compile already with -fno-rtti too (unless the feature is really
strictly about type_infos)

Paolo.