Hi Mario,
sorry about the delay but I was busy with other things yesterday.
W dniu 02.02.2015 o 21:37, Mario Schuknecht pisze:
Hi Andrzej,
thank you for the comment.
<snip>
I'm not sure I understand the logic of the below function well.
+static inline int usb_ext_prop_put_unicode_multi(u8 *buf, int pnl,
+ const char *string, int data_len)
+{
+ int outlen = 0;
+
+ put_unaligned_le32(data_len, usb_ext_prop_data_len_ptr(buf, pnl));
+
+ while (*string && outlen < data_len - 2) {
You keep looping as long as the source *string is not '\0'
and advance the string in each loop by adding (strlen() + 1) of
what is currently available starting at *string.
For example:
string: "a\0b\0and this is past the end of your source buffer"
first loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: "b\0and this is past the end of your source
buffer" */
second loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: "and this is past the end of your source
buffer" */
so effectively the first part of the while condition rarely ever becomes
"false".
In other words when you process all the source strings from "string" you, by
design,
end up one byte past the terminating '\0' of the source buffer. The contents
of this memory can be anything, there is just 1/256 chance it is zero,
so the "while (*string" part does not make sense to me.
The assumtion is that the input string is also double Nul-terminated.
E.g. "one\0two\0three\0\0"
Should I add a parameter "inlen" which contains the input buffer length?
Ah, right. Now I see your point. You need to be able to tell
whether the current "sub"string is the last one or not.
Or can I trust that the input string is double Nul-terminated?
Extended Properties support is meant primarily to be used with the
configfs interface. The user creates a directory in <function>/interface.<name>.
The name of the directory becomes the name of the property. Inside
the directory there are two attribute files: "data" and "type".
The user stores numeric type id into "type", in this case "7".
And then the user stores property's contents into "data".
From this perspective double termination seems awkward,
as a user I would expect that I just store a sequence of
NUL-terminated strings without additional terminator.
But this approach implies passing some additional information
to usb_ext_prop_put_unicode_multi() instead.
AP
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
