> 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'
FX wrote:
I think the best thing to do is to have a langhook then.
It seems a bit weird to have a langhook for a one-character
difference, but if there's a consensus on it, I'll go along.
To me too, but I still maintain that it's better to print in UTF-8
(which would make the langhook more u
> I think the best thing to do is to have a langhook then.
It seems a bit weird to have a langhook for a one-character
difference, but if there's a consensus on it, I'll go along.
> Endianness issues may also appear. Maybe you should call iconv in the
> langhook to get back to UTF-8, and print t
Notice the added final '\0' in the C case; I don't know if it's bad to
have it there, but I don't see a way to not output it and still have
the correct output for Fortran (whose strings are not NUL-terminated).
I think the best thing to do is to have a langhook then. I'm actually
not sure th
> Yes, it is bad to have it there for C/C++, please make sure the final
> \0 isn't printed.
The question is: how? If we limit the tree dumps to C/C++ semantics,
then there's no way they can express Fortran code (ie a string
litteral not terminated by a NUL), is there? Or do we make the
semantics o
On Mon, May 19, 2008 at 02:59:16PM +0100, FX wrote:
> return (unsigned char *) "look\0here\0";
>
>
> Notice the added final '\0' in the C case; I don't know if it's bad to
> have it there, but I don't see a way to not output it and still have
> the correct output for Fortran (whose strings are
Hi there,
On Mon, 19 May 2008, 15:59:16 +0200, FX wrote:
> [...]
> Any comments? Is it OK to commit as is?
this may sound like nit-picking, but the length of a string cannot be
negative, so, I'd rather make the new parameter `len' an "unsigned int"
or even size_t.
HTH, cheers.
l8er
manfred
Hi all,
The Fortran front-end now handles wide character strings
(UCS-4/UTF-32); for these, the string literals are emitted as strings
with the type of an array of unsigned 32-bit integers. The issue is
that tree-pretty-print.c, in pretty_print_string() assumes strings are
composed of chars and NU
