On Wed, Feb 4, 2009 at 1:23 PM, Daniel Marschall
<info_at_daniel-marschall.de> wrote:
> I am very confused at the moment. Can you please help me? I don't know what
> to do. It doesn't work...
> Now I have again a memory-access-error :-(
>
> static int writer(char* data, size_t size, size_t nmemb, char* buffer)
> {
> // What we will return
> int result = 0;
>
> // Is there anything in the buffer?
> if (buffer != NULL)
> {

This doesn't check for an empty buffer, just a null pointer. I think
the comment is incorrect but the logic is ok although possibly
unnecessary since you realloc the buffer.

> buffer = (char*)realloc(buffer, size * nmemb); // Extend the
> buffer

This might create a new buffer that the original buffer no longer
points to. And size is not cumulative so you will only allocate enough
for this invocation of writer.

>
> // Append the data to the buffer
> strcat(buffer, data);

You should probably use memcpy since data is not necessarily a string
and may contain NULL. Not only that but if realloc gave back a
different buffer, you need to copy the original buffer to the new one.

>
> // How much did we write?
> result = size * nmemb;
> }
>
> return result;
> }
>
> // Pufferoptionen
> curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);
> char errorBuffer[CURL_ERROR_SIZE];
> curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, errorBuffer);
> //char* buffer;
> char *buffer = (char*)malloc(12); // Make a too tight buffer
> buffer[0] = '\0'; // Initialize the buffer
> curl_easy_setopt(curl, CURLOPT_WRITEDATA, buffer);
>
>
> I fear that I destroy things in my memory. My output is now.
>
> A
> àøtá·`!A
> PuTTYPuTTYA
> PuTTYpA
> PuTTYA
> PuTTY
>
> Please help.
>
> --------------------------------------------------
> From: "Daniel Marschall" <info_at_daniel-marschall.de>
> Sent: Wednesday, February 04, 2009 7:12 PM
> To: "libcurl development" <curl-library_at_cool.haxx.se>
> Subject: Re: cURL bug -- Segmentation Fault when timeout is 1 second
>
>> Hello.
>>
>> I will try to extend the writer-function, so that it extends the buffer.
>>
>> But the website http://www.example.com/ is a text-only page. So it should
>> not be that my buffer has binary data at the beginning. And please look at
>> my code and output:
>> - The first call did output the website correctly
>> - The second call had binary garbage at the beginning
>> - The third call had other binary garbage at the beginning
>> And every call should be the same since the functionality is independent
>> of parameters!
>>
>> I never used strncpy() or any similar function in my codes. Maybe you have
>> looked at the wrong example code? I used the haxx.se example code of the
>> writer function that used std::string->append().
>>
>> Regards
>> Daniel Marschall
>>
>> --------------------------------------------------
>> From: "Gary Maxwell" <gmaxwell_at_casabi.com>
>> Sent: Wednesday, February 04, 2009 7:01 PM
>> To: "libcurl development" <curl-library_at_cool.haxx.se>
>> Subject: RE: cURL bug -- Segmentation Fault when timeout is 1 second
>>
>>> Daniel Marschall on February 04, 2009 9:49 AM wrote:
>>>>
>>>> But there are 2 problems I still have:
>>>>
>>>> 1. I want to have an infinite big buffer, like a std::string in C++.
>>>
>>> If
>>>>
>>>> the
>>>> website-output is larger than the buffer size, then I get a
>>>> memory-access-error again.
>>>>
>>>> Isn't "char*" an infinite c-string that waits for an 0x0 termination
>>>> sequence, is it?
>>>
>>> "char*" is certainly NOT an infinite c-string. It is simply a pointer
>>> to an area of memory that contains sequential characters, the
>>> size of which you determine when you statically define or dynamically
>>> allocate the memory.
>>>
>>> You can easily expand the size of your buffer in the write callback
>>> function. Look at the documentation for realloc().
>>>
>>>>
>>>> 2. The output of the buffer with printf() is not correct. Some foreign
>>>> memory contents are in my string... The output is like:
>>>>
>>>
>>> Whoever said that the response from the server would be printable
>>> UTF-8 data? The server will send back whatever data it thinks you asked
>>> for, be it text, images, or sound bites. This is what particularly
>>> alarmed me in your earlier example code, using strncpy() in the write
>>> callback. You should instead use memcpy().
>>>
>>> -GaryM at casabi
>>>
>>
>
Received on 2009-02-04