Christian Schulte <cs@schulte.it> writes:
>
> You just drove me into booting my Falcon030 and compare Pure Pascal to
> Pure C with regard to string handling. Passing a string around in
> Pascal, that string implicitly carries a length property. Passing a
> string around in C, that string does not carry any implicit properties
> denoting it a string. In C, just never pass a char * without a
> corresponding size_t denoting buffer/string length. I am still confused
> about that memcmp in kern_unveil.c, though. Seems to be a very clever
> trick to include string termination in that comparison, I am just not
> getting yet.

In C, the classical way to represent a string is to have a pointer on
the first char of the string, and have NUL char at end ('\0' or NUL).

It means that the both variables below have the exact same encoding in
the binary (when using a C compiler) :

  char *var1    = "foobar";
  char  var2[7] = { 'f', 'o', 'o', 'b', 'a', 'r', '\0' };

memcmp() function is only comparing range of memory. when used against
strings, you need to compare the NUL terminal to be sure it is the same
string (and not a substring).

  char var3[4] = { 'f', 'o', 'o', '\0' };   /* = "foo" */

comparing var2 and var3 using memcpy():
  memcmp(var2, var3, 3) /* => 0 (identical) */
  memcmp(var2, var3, 4) /* => !0 (not identical: 'b' != '\0') */

In kernel, the rules could ne a bit different, in the way you might
prefer to use the Pascal style (pointer + len) or using two pointers
(beginning-pointer and ending-pointer) for performance reasons when
dealing a lot with substrings or string scanning.

If using NUL terminated string, you need to copy the substring and add
NUL at end, whereas in the other case you just get a pointer on the same
memory block and you adjust the length (assuming no change on the raw
bytes).

Regards.
-- 
Sebastien Marie