Attention is currently required from: Edward O'Callaghan, Angel Pons, Anastasia Klimchuk.
3 comments:
File tests/init_shutdown.c:
I started reading man page for fnmatch() and realised I am not sure what the end goal is. […]
Hmmm, what I hoped for doesn't work. I expected fnmatch() to
strip superfluous slashes before the comparison, then something
like this would have returned 0:
fnmatch("/sys/class/mtd/mtd0/type", "/sys/class/mtd/mtd0//type", 0);but it doesn't. My idea was that we have an accurate pathname
and would check if whatever is passed to fopen() would result
in opening that path. I couldn't find any solution using POSIX
functions, though. I guess what the real fopen() (and open())
do is to walk the actual path right away. Something we can't
do when mocking the paths unless we'd actually parse the path
passed to fopen() (which seems a bit too much).
File tests/init_shutdown.c:
Do I understand you correctly, if there is a linebreak sometimes then we still need +1 to strlen?
Um, no. If we'd decide to end the strings with a '\n' that would
be part of the string. It's not necessary that we do it, as the
linux_mtd driver already accepts strings with and without a trailing
new-line.
The length should just match what we copy into the buffer. But I
don't see why we should copy the '\0' into the buffer. This is
something we wouldn't read when opening the actual file in sysfs,
right?
File tests/init_shutdown.c:
Patch Set #10, Line 239: strncpy(buf, entry->data, data_len);
Just noticed: used like this, isn't it doing the same as memcpy()?
Using strncpy() generally is odd (some people call it dangerous).
It has one interesting trait: clearing the unused bytes of the buffer;
but that's actually avoided by the min() above. So why use strncpy()?
To view, visit change 56413. To unsubscribe, or for help writing mail filters, visit settings.