Fwd: Re: Segmentation fault on append to Glib::ustring





-------- Messaggio originale --------
Oggetto: Re: Segmentation fault on append to Glib::ustring
Data: Sat, 10 Dec 2011 11:56:59 +0100
Mittente: Spazzatura.Live <kharhonte hotmail com>
A: Kjell Ahlstedt <kjell ahlstedt bredband net>
CC: gtkmm-list gnome org


Hi Kjell,

many thanks, in particular because you have lost your time reading libcurl tutorial to help me.

My mistake was in reading a Python source which did the same job and i translated it into C++ (infact, in Python, calling WRITEFUNCTION with a StringIO, doesn't require WRITEDATA) without learning anything about libcurl but what i seem to need for.

However, now it seem to work, also with Glib::usting::append(). However, does a html contain encoded unicode characters? How should i use a Glib::ustring in this case? (As i told, i use it for compatibility reason, so if it's possible it should be better keeping it instead of casting it after)

I attach the new working code.

Thanks.
Cheers,
Stefano

P.s. 1) Forgot the code. 2) I've seen the Wikipedia japan page source and it does contain the characters, not just the " &#12354;" like code. Sorry for the ignorance...

Il 10/12/2011 10:49, Kjell Ahlstedt ha scritto:
Hi again Stefano,

I became curious and read the beginning of the libcurl tutorial at http://curl.haxx.se/libcurl/c/libcurl-tutorial.html.
It seems quite clear that both
  curl_easy_setopt(handle, CURLOPT_WRITEFUNCTION, writefunction)
and
  curl_easy_setopt(handle, CURLOPT_WRITEDATA, &data)
must be called before
  curl_easy_perform(handle)

In your program
  curl_easy_setopt(handle, CURLOPT_WRITEDATA, &data)
is not called. If you uncomment
  g_print("%s", curl.get_data().c_str())
in timsms.cc,
  curl_easy_setopt(handle, CURLOPT_WRITEDATA, &data)
will be called, but too late. writefunction() has already been called (when curl_easy_perform() was called), and probably with buffer==0.

You must still change the call to Glib::ustring::append(). You can't use Glib::ustring::append(const char* src, size_type n) unless the data is purely 7-bit Ascii. And if it's neither 7-bit Ascii nor UTF-8 encoded Unicode, you should not use Glib::ustring.

Kjell

2011-12-09 23:07, Spazzatura.Live skrev:
I thought about it, but the problem is with the unreferencing of the Glib::ustring, not with the data (however if it tries to append a shorter string in a larger space it shouldn't be a problem, i think. (The matter could be if he tries to read more characters than the char * has allocated.)) Even if i try, in the "writefunction" to do anything else with the Glib::ustring it fails with segmentation fault.

Tomorrow morning i'll try the way you suggested me and i'll let you know.

The data is a website content and for compatibility reason (with the other application's function) i used Glib::ustring, but if i try with std::string the result is the same.

Thanks for the answer.
Stefano.

Il 09/12/2011 20:47, Kjell Ahlstedt ha scritto:
Hi,

I don't know anything about libcurl, and I haven't tried to build and execute your program. I've just studied your code a bit.

Are you aware that n in Glib::append(const char* src, size_type n) is _not_ the number of bytes to append? It's the number of UTF-8 encoded Unicode characters.

If size*nmemb in writefunction() is the number of bytes to append, and data contains utf-8 encoded data with multi-byte characters, buffer->append(data, size*nmemb) will try to append too much. You can try using template<class In> Glib::ustring& Glib::append(In pbegin, In pend):
  buffer->append(data, data + size*nmemb);
If data does not contain utf-8 encoded data, you should not use Glib::ustring.

Kjell


Attachment: code.zip
Description: Zip archive



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