Fwd: Re: Segmentation fault on append to Glib::ustring
- From: Spazzatura.Live <kharhonte hotmail com>
- To: Kjell Ahlstedt <kjell ahlstedt bredband net>
- Cc: gtkmm-list gnome org
- Subject: Fwd: Re: Segmentation fault on append to Glib::ustring
- Date: Sat, 10 Dec 2011 12:01:37 +0100
-------- Messaggio originale --------
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 "
あ"
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]