Re: [RFC] Adjust output for strings in tree-pretty-print.c

[FX <fxcoudert at gmail dot com>]

> To me too, but I still maintain that it's better to print in UTF-8 (which
> would make the langhook more useful).  The recent Unicode patches for C
> possibly could use the langhook too.

OK, I need to focus on making progress and fix the current behaviour,
which is broken for gfortran (ie doesn't allow us to use tree dumps at
all). So, if people want to deal with Unicode tree dumps, that's fine
(though, as a matter of taste, I'd still prefer having the bit
pattern), but that's not the object of this patch.

To deal with the difference in behaviour between the C family and
Fortran, a langhook function is a bit overkill (it needs a callback
function which in turns calls pp_character to actually display things,
in order to be generic and usable in various parts of the middle-end),
I just added a flag (null_terminated_strings): it defaults to true,
but Fortran sets it to false. Depending on this value,
tree-pretty-print.c will behave the right way. I attach the
preliminary patch here, to know if it's OK to go ahead. If so, I'll
add documentation and submit for proper review.

Also, I'd like to know if it's deemed suitable to use that flag in
tree-dump.c (look for TREE_STRING_POINTER in that file). Currently,
calling debug_tree() on a STRING_CST will display null characters,
like "This is a string.\0", which is apparently unsuitable for C. So,
should I use the new flag here also?

> But for testing you want a standardized endianness.  Otherwise some targets
> will need to scan "I\0\0\0" and others will need to scan "\0\0\0I".

That's debatable. I prefer being able to see the byte sequence in the
tree dumps to make sure it's as expected.

FX

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/