Miroslav,
On 9/10/21 11:52 PM, Miroslav Zagorac wrote:
Hello Tim,
On 09/10/2021 10:55 PM, Tim Düsterhus wrote:
If it's not a NULL pointer then it must be a valid pointer. I don't
quite understand why you would need to replace this by an empty constant
string then? Is this about a missing NUL terminator? Otherwise a valid
pointer with .len == 0 would be equivalent to "".
No, v.ptr is not a null pointer and points to the wrong location, v.len
is equal to 0.
For example I added to the source two calls to the printf () function,
one before the htx_get_blk_value() function call and the other after:
---------
printf(">>> n = { %p '%s' %zu }, v = { %p '%s' %zu }\n", n.ptr, n.ptr,
n.len, v.ptr, v.ptr, v.len);
v = htx_get_blk_value(htx, blk);
printf(">>> v = { %p '%s' %zu }\n", v.ptr, v.ptr, v.len);
---------
I intentionally did not write the string format as '%.*s' so that the
contents can be seen. These two headers are treated here:
1, 'ot-ctx-uberctx-haproxy_id: '
2. 'ot-ctx-uber-trace-id: 3c4069d777e89019:3c4069d777e89019:0:1'
, and this is the result:
1st header:
>>> n = { 0x56079098bec1
'ot-ctx-uberctx-haproxy_idot-ctx-uber-trace-id3c4069d777e89019:3c4069d777e89019:0:1'
25 }, v = { (nil) '(null)' 0 }
>>> v = { 0x56079098beda
'ot-ctx-uber-trace-id3c4069d777e89019:3c4069d777e89019:0:1' 0 }
As can be seen from the example, v.ptr = 0x56079098beda, v.len = 0.
This looks correct to me. The value points to the location right behind
the name of the header and has length 0. The header is empty, thus the
'v' is empty as well, as indicated by v.len == 0. Thus accessing any
byte of this zero-size "buffer" is effectively undefined behavior.
2nd header:
>>> n = { 0x56079098beda
'ot-ctx-uber-trace-id3c4069d777e89019:3c4069d777e89019:0:1' 20 }, v = {
(nil) '(null)' 0 }
>>> v = { 0x56079098beee '3c4069d777e89019:3c4069d777e89019:0:1' 37 }
This also looks correct to me.
Maybe I use htx_get_blk_name()/htx_get_blk_value() in this function in
an inappropriate way, so I get such a result.
Unrelated to that: Having worked quite a bit with the ist API I would
generally recommend using the helper functions in ist.h (possibly adding
new ones if they are helpful) instead of directly touching the struct.
It makes refactoring much easier, because it's easy to find the function
calls vs. accessing struct members which might be available on different
structs.
As an example in flt_ot_http_headers_get you could use an ist for prefix
and then simply use isteqi() instead of strncasecmp().
The functions strncasecmp() and isteqi() are not compatible, because
isteqi() requires that the lengths of the strings being compared are
equal, whereas in this function that is not the case. In addition, the
prefix and len should be put in the ist structure and n.len reduced to
the size of len, this is an unnecessary complication.
You are right of course. For some reason I thought you wanted to compare
for equality and used the 'n' variant because they strings are not NUL
terminated.
The programming style in OT is not what I'm used to, but if I understand
it correctly then maybe istmatchi() is what you are searching for (it
matches prefixes which should be what you are doing manually)?
Best regards
Tim Düsterhus
