Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
DEBUGFUNCTION manual says data is not zero-terminated, but the example could assumes that it is
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Oskar Sigvardsson via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 7 Nov 2022 05:40:58 -0500
Hi!
I had a question about a thing that wasn’t quite clear to me in the manual.
I want to hook up a custom logging function using CURLOPT_DEBUGFUNCTION,
and the docs are pretty clear that the info passed in will not be
zero-terminated:
(from https://curl.se/libcurl/c/CURLOPT_DEBUGFUNCTION.html )
CURLOPT_DEBUGFUNCTION replaces the standard debug function used when
CURLOPT_VERBOSE is in effect. This callback receives debug information, as
specified in the type argument. This function must return 0. The data
pointed to by the char * passed to this function WILL NOT be
null-terminated, but will be exactly of the size as told by the size
argument.
Which seems clear enough. However, a little bit further down, we have some
example code for how you might write this function, and it has this in it:
switch (type) { case CURLINFO_TEXT: fprintf(stderr, “== Info: %s”, data);
fprintf with the %s argument requires zero-terminated strings, so either
this example is a stability/security hazard, or if the type is
CURLINFO_TEXT, then the string actually is guaranteed to be zero
terminated. Right? I’m assuming it’s the latter, and that for the info
strings curl just formats a C-string internally so that this is actually
not a problem.
In any case, the example should match the docs: it seems less than ideal
for me for the docs to have this very strong warning which the example code
immediately violates. Either the docs should be updated to state that it’s
actually fine for CURLINFO_TEXT to assume zero-terminated strings, or the
example code should be adapted to not have this assumption in it (it
certainly should be if it’s NOT fine to assume zero-terminated stringss for
CURLINFO_TEXT).
Oskar Sigvardsson
Date: Mon, 7 Nov 2022 05:40:58 -0500
Hi!
I had a question about a thing that wasn’t quite clear to me in the manual.
I want to hook up a custom logging function using CURLOPT_DEBUGFUNCTION,
and the docs are pretty clear that the info passed in will not be
zero-terminated:
(from https://curl.se/libcurl/c/CURLOPT_DEBUGFUNCTION.html )
CURLOPT_DEBUGFUNCTION replaces the standard debug function used when
CURLOPT_VERBOSE is in effect. This callback receives debug information, as
specified in the type argument. This function must return 0. The data
pointed to by the char * passed to this function WILL NOT be
null-terminated, but will be exactly of the size as told by the size
argument.
Which seems clear enough. However, a little bit further down, we have some
example code for how you might write this function, and it has this in it:
switch (type) { case CURLINFO_TEXT: fprintf(stderr, “== Info: %s”, data);
fprintf with the %s argument requires zero-terminated strings, so either
this example is a stability/security hazard, or if the type is
CURLINFO_TEXT, then the string actually is guaranteed to be zero
terminated. Right? I’m assuming it’s the latter, and that for the info
strings curl just formats a C-string internally so that this is actually
not a problem.
In any case, the example should match the docs: it seems less than ideal
for me for the docs to have this very strong warning which the example code
immediately violates. Either the docs should be updated to state that it’s
actually fine for CURLINFO_TEXT to assume zero-terminated strings, or the
example code should be adapted to not have this assumption in it (it
certainly should be if it’s NOT fine to assume zero-terminated stringss for
CURLINFO_TEXT).
Oskar Sigvardsson
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-11-07