Re: Suggestions for libstdc++-2.90.6

[Benjamin Kosnik <bkoz@cygnus.com>]

> Compiling this fails, with complaints about lines 669, 678, and 681
> of stl_vector.h. The following diff fixes things:
> 
> *************************
> 
> 669c669
> <     copy_backward(__position, _M_finish - 2, _M_finish - 1);
> ---
> >     copy_backward(__position, iterator(_M_finish - 2), iterator(_M_finish-1));
> 678c678,679
> <       __new_finish = uninitialized_copy(_M_start, __position, __new_start);
> ---
> >       __new_finish = uninitialized_copy(iterator(_M_start), __position,
> >          __new_start);
> 681c682,683
> <       __new_finish = uninitialized_copy(__position, _M_finish, __new_finish);
> ---
> >       __new_finish = uninitialized_copy(__position, iterator(_M_finish),
> >          __new_finish);

This in, thanks. I've thought about trying to re-integrate the stlport 
testsuite--it is probably the best way to go about testing the stl.

Anybody who is intersted in volunteering for this, please email me.

> #include <iostream>
> #include <fstream>
> 
> int main(int argc, char* argv[])
> {
>    if (argc < 3) { cerr << "No filenames" << endl; return 1; }
>    filebuf fbin, fbout;
>    fbin.open(argv[1], ios::in);
>    if (!fbin.is_open()) 
>     { cerr << "Cannot open " << argv[1] << endl; return 2; }
>    fbout.open(argv[2], ios::out|ios::trunc);
>    if (!fbout.is_open())
>     { cerr << "Cannot open " << argv[2] << endl; return 3; }
> 
>    istream is(&fbin);
>    is.unsetf(ios::skipws);
>    is >> &fbout;
> 
>    fbout.close();
>    fbin.close();
> 
>    return 0;
> }

Fixed in a different way. The extractor for streambufs was actually 
incorrect.

> #include <iostream>
> #include <fstream>
> 
> int main()
> {
>    filebuf fb;
>    fb.open("number", ios::in);
>    if (!fb.is_open()) { cerr << "No file" << endl; return 1; }
>    istream is(&fb);
>    int n = 15;
>    is >> n;
>    cout << "That was " << n << endl;
>    char c = is.peek();
>    cout << "Next character: " << (int) c << endl;
>    return 0;
> }

> With more difficult input, in number, I could cause segmentation
> faults.

Note that stringbufs can be used to reproduce this as well. IF you have 
more difficult input that is crashing, by all means please post it.

> *************************
>   // The thought was to encapsulate the conversion
>   // into this one function, and thus the num_get::do_get member
>   // functions can just adjust for the type of the overloaded
>   // argument and process the char array returned from _M_extract.
> *************************
> 
> With respect, I don't see how this can work without some additional
> machinery. The template functions num_get::do_get are based on the

Right. Different bases and floating point types were not even attempted. 
That's really a placeholder for the final solution, perhaps the comments 
weren't that elaborate.

> The minimal extra machinery I could think of was to give an extra
> boolean argument to _M_extract, true by default, but set to false for
> extracting integer rather than floating-point types. _M_extract can
> figure out by itself what the base is, but not the type of number to
> be extracted, and a one-pass algorithm needs to know. Here is my diff
> for the file locale_facets.tcc:

Sounds like a good way to start, but I cannot figure out or apply your 
patch without a bit more context. I've partially applied this (see the CVS 
files.)

Can you please run a "cvs diff -cp" against the CVS version of the 
diffs, then send me the results so I can integrate your work for 
_M_extract? I also put in the hooks for all integral types, as there is 
really no sense in doing this just for ints.

> Two more points, and I'll be done for now. In my various experiments,
> I used the unformatted extractor istream::read(char*, streamsize n)
> at one point. As written, this function reads n+1 characters. The
> diff, for the file std_istream.h, is:

yeah, it's more than just get(char), it's all the unformatted istream 
functions. This fixed now, thanks.


> This change returns the byte 0xff as the int 0x000000ff, and eof as
> 0xffffffff, as desired. For most purposes, it is also better that it
> returns the byte 0xfe as 0x000000fe rather than as 0xfffffffe,
> although it often doesn't matter.

OK cool. This is in too. Is there a testcase for this?

> Well, that's it; sorry the list is so long. As the BUGS list says,
> istream::get(char) is not working for cin. I'm afraid I'll have to
> leave that to you, although I hope someone fixes it soon!

Thanks for all your hard work. If you could re-send the locale-specific 
parts of the patch, I'll put them in.

-Benjamin