Alexander Kanavin <[email protected]> writes:
> Collin has explicitly said he is not endorsing the use of GNU tests for
> uutils.
Any implementation is free to use the GNU coreutils test suite, as long
as its licensing is respected, of course. It mostly just involves
fetching it from git, changing the PATH used by the tests to point to a
separate directory with the relevant binaries, and maybe applying some
patches for different error messages, for example. I don't think you
meant to imply otherwise, but I just wanted to make sure it wasn't
misinterpreted by other readers.
My comment was just to say that a high passing rate on the GNU coreutils
test suite doesn't necessarily mean two implementations are compatible.
A made-up example, based on some behaviors I have seen previously with
other programs, though I forget which, a test might check if 'shred'
checks for invalid file types by redirecting standard error to a file
here:
$ mkfifo fifo
$ shred fifo
shred: fifo: invalid file type
If one implementation uses open ("fifo", O_NONBLOCK | ...), and the
other uses statx, which I commonly see uutils do through std::fs
functions, then the behavior will be different on readers waiting for a
writer. The open will unblock the reader, while statx will not.
Behaviors like this aren't always tested, though; the GNU coreutils test
suite is always a work in progress. I have tried to improve the checks
for cases like this, but there are theoretically more niche cases that
could cause problems if behavior changes.
Collin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#247740):
https://lists.openembedded.org/g/openembedded-core/message/247740
Mute This Topic: https://lists.openembedded.org/mt/121685421/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
