Attention is currently required from: Edward O'Callaghan, Angel Pons, Anastasia Klimchuk. Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/56413 )
Change subject: tests: Mock file i/o for linux_mtd and linux_spi tests ......................................................................
Patch Set 10:
(3 comments)
File tests/init_shutdown.c:
https://review.coreboot.org/c/flashrom/+/56413/comment/7f5dbcac_bb0a3c7c PS4, Line 219: //
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:
https://review.coreboot.org/c/flashrom/+/56413/comment/ab2a3259_a77bbbb6 PS9, Line 236: + 1
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:
https://review.coreboot.org/c/flashrom/+/56413/comment/5fe38571_769bedb4 PS10, 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()?
-
Nico Huber (Code Review)