[GRASS-dev] [grass-code I][455] r.proj segfaults after Jul 14 changes

[Paul Kelly]

On Thu, 9 Aug 2007, Hamish wrote:

> However, G_message(""); for a blank line is ugly ugly, I'd suggest either
> adding a new lib fn (lame solution) or removing whitespace stripping action
> from G_message(), and allow '\n' back in the string. The problem with this is

Well yes - if it does that then that explains why people are passing an 
empty message. It's acting more like G_print_this_info_to_stderr() than a 
real G_message(). IMHO a message should be a distinct piece of 
information, that may or may not require multiple lines to get across. The 
calling modules should be able to add line breaks if they see fit. I also 
think G_message(), G_warning() etc. should only break lines if output is 
going to a terminal. When the messages are re-processed and displayed 
through the GUI the extraneous line breaks can look quite ugly in certain 
circumstances (e.g. pop-up dialog boxes containing warnings).

Allowing newlines in messages passed to G_message() but then stripping 
them out strikes me as really messy, and just lazy - why not fix all the 
calls to G_message() instead to conform to the conventions?

> that self-formatting gets abused, and perhaps confuses the line-wrap code?

Hmm, what do you mean by abused? I feel that the programmer should be able 
to put newlines into a message if it is necessary to get the meaning 
across, and the function that prints/parses the output should respect the 
newlines.

Paul