On 14 March 2011 05:53, Matthew Brush matthewbrush@gmail.com wrote:

On 03/13/11 03:19, Lex Trotman wrote:

...

I don't think this is a good idea since g_strstrip() doesn't actually change the size recorded in the GString, it might appear to work sometimes but it might also fail. Note that a GString also does not have to be null terminated so the g_strstrip might write beyond the buffer if you are unlucky.  I think you are better not to do this.

I have updated the patch (see attachment) to be more safe, based on your comments.  I'm not 100% confident this is the Best Way, but maybe if someone has time to review the way it's being done, they could fix it or suggest the best way.  My idea is to allocate a buffer filled with zeroes, one bigger than the ->len size, copy the ->str member into the new buffer, except its

Well it looks like it will work, but see below.

nul char, and the new buffer is sure to have at least a nul at the end.  After, the new buffer is stripped of whitespace and split into lines.  From reading the GString docs, it sounds like the ->str member *is* always nul

You're right, it is guaranteed to be nul terminated.

terminated, but this way is safe even if it isn't, I think.

Is this better?  Overkill?  Stupid?

Sorry to do this to you Matthew, but I think that there is a problem with the original code and I think that might also bite you.

It seems to me that the assumption is that the template file encoding is UTF-8 or ASCII (as a subset of UTF-8) as its contents are just pasted straight into the Scintilla buffer. The standard templates are ASCII, but it may not be true for user defined templates, for instance Enrico has non-ASCII characters in his name.

I am not sure how well the g_str and g_string functions work in this case. Can someone with more understanding of such things comment. Should the templates be passed through encodings_convert_to_UTF_8?

Cheers Lex

Cheers, Matthew Brush (codebrainz)