Re: GtkSourceViewmm bug



Errr, oops, the implementation in the snippet above should actually read:

Glib::RefPtr<SourceLanguage> SourceLanguageManager::guess_language(const Glib::ustring& filename, const Glib::ustring& content_type)
{

  Glib::RefPtr<SourceLanguage> retvalue = Glib::wrap(gtk_source_language_manager_guess_language(gobj(), filename.c_str(), content_type.c_str()));
  if(retvalue)
    retvalue->reference(); //The function does not do a ref for us.
  return retvalue;
}

I had forgotten to undo my hacky workaround before pasting. Sorry!
-Adrian

On Tue, Jul 13, 2010 at 4:49 AM, Adrian Petrescu <apetresc gmail com> wrote:
Hey guys,

I'm working off the latest tagged release of libgtksourceviewmm, which is gtksourceviewmm-2.10.0, and noticing that there's a significant bug.

In the SourceLanguageManager, there's supposed to be a "guess_language" function with the following implementation:


Glib::RefPtr<SourceLanguage> SourceLanguageManager::guess_language(const Glib::ustring& filename, const Glib::ustring& content_type)
{

  Glib::RefPtr<SourceLanguage> retvalue = Glib::wrap(gtk_source_language_manager_guess_language(gobj(), filename.c_str(), NULL));
  if(retvalue)
    retvalue->reference(); //The function does not do a ref for us.
  return retvalue;
}



The semantics are supposed to be that you pass in both parameters, but only one or the other are non-NULL (it doesn't know what to do if you specify both or neither). However, if you actually try to call it with NULL for either one of the two values, you fail with:

 terminate called after throwing an instance of 'std::logic_error'
   what():  basic_string::_S_construct NULL not valid

Whereas if you pass in an empty string instead, you fail differently with:

(algoviz:12581): GtkSourceView-CRITICAL **: gtk_source_language_manager_guess_language: assertion `(filename == NULL || *filename != 0) && (content_type == NULL || *content_type != 0)' failed

I've confirmed that this is just a mapping error by replacing the content_type.c_str() call with "NULL" directly in the source code, and it worked fine after that. But I thought I'd point this bug out to the list, since the function is pretty useless the way it is right now since it's uncallable.

Cheers!
-Adrian



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]