> Please also make sure that you patch does not introduce any regression
> in our testsuite. Do you know how to test it? Basically, we run the
> testsuite before and after applying your patch, and verify that it
> does not introduce any new failures by comparing the gdb.sum files
> produced before and after.  Please also make sure to mention which
> architecture this was tested on (typically x86-linux or x86_64-linux).

Tested on x86-linux. I have one regression and fix it.

> This is not a blocking comment, meaning that this is not a request
> to fix before your patch gets accepted, but I'm starting to think
> that the way you use your unbounded_string is to build the output
> before printing it.  We typically would use a "ui_file" stream,
> for that. In your case, you want a "memory" ui-file.  Have a look
> at ui-file.h, and in particular at mem_fileopen, ui_file_write,
> and ui_file_xstrdup.  That should provide you all the infrastructure
> you need to get rid of this local "unbounded_string" type.
> 
> I'll give you the choice: Look at this as part of this patch, or
> promise me that you'll look at it soon after this patch is in our tree.

You right, but in unbounded_string we allocate what we needed + 20 byte.
It allows to call allocation of memory less often. This way chose John
Demme. It effective way, when we need allocate many unbounded buffers
with big size. But in ours case we need only on small buffer. 
I prefer another way - just allocate one buffer with size bigger than
worst case. It important in case with D language, as it can create only
static library at now. I do some test:

If we use ui_file we need call allocate 10275 times for "hello world"
and 86076 for real medium project on startup GDB.
If we use unbounded_string - 3130 and 25494.
If we use one buffer - 1214 and 8882.

Worst case size of buffer was 173 byte.

> > +	if (ret != -1)
> > +	   break;
> > +      default:
> > +	ret = c_val_print (type, valaddr, embedded_offset, address, stream,
> > +			   recurse, options);
> 
> This is surprising me a little. Don't you have plain struct types
> that are not dynamic arrays? Right now, the code seems to indicate
> that you don't expect any. Or maybe I missed something?

Look at this again. If we don't have dynamic array we ret -1. In this
case ret == -1 and we jump to default.