Re: Timeline for 1.1.20?

[Christopher Friedt <chrisfriedt@gmail.com>]

On Sat, Jul 28, 2018 at 3:55 PM Rich Felker <dalias@libc.org> wrote:
> Yes, but I don't know how to set it up, and any proper approach to
> setting it up really shouldn't require the project maintainer to know
> how, since it should revolve around a separate CI project pulling
> musl, libc-test, and possibly other sources (e.g. mcm) as either
> subrepos or part of the build scripts, then evaluating the resutls.

I'll set up a .gitlab-ci.yml file - likely will use one 'pipelilne' to
trigger other pipelines that exercise all combinations here:

https://github.com/richfelker/musl-cross-make#supported-targets

Speaking of which, one of my eventual use-cases is an rtos that uses
the same syscall numbers as linux for each arch. Originally I was
using bionic libc, but it's just difficult to maintain a permanent
fork. Beyond syscall numbers, is there any specific reason that musl
requires linux?

> As for the immediate need, though, it's *not* fancy CI processes but
> actual test coverage. I'm really wary of projects that have fancy
> process frameworks but nothing to show for it.

Reports are useful. The fancy processes (automation, etc) just make
life easier in the end and they're pretty easy to set up after one or
two projects. I usually prefer to get it out of the way early. The
low-hanging fruit. For unit testing, it's helpful to adopt a
framework. gtest is good, although it assumes you have a working c++
compiler.

I get that you want to keep libc-test and musl separate for now, but
normally test code is part of the same repository as the source it's
testing. Maybe consider that in the future.

> In particular, coverage for changes since 1.1.19 would include:
>
> - getrandom/getentropy basic functionality check
> - setvbuf non-stub inplementation: basic functionality, check for
>   writes outside the buffer, etc.
> - malloc interposition: check that partial replacement doesn't result
>   in unsafe behavior.
> - pthread_create: confirm that scheduling and other attributes still
>   work as expected after refactoring work.
> - getddrinfo AI_ADDRCONFIG (can't really be tested without network
>   namespaces though)
>
> Particular bugfixes that call for functionality or regression tests:
>
> b123f23 fix getopt wrongly treating colons in optstring as valid option chars
> 0cf5058 fix nl_langinfo_l(CODESET, loc) reporting wrong locale's value
> 282b1cd fix fmaf wrong result
> ae2a01d fix wrong result in casin and many related complex functions
> 10e4bd3 fix incorrect results for catan with some inputs
> 4bf0717 fix return value of nice function
> 3f6dc30 fix out of bounds write for zero length buffer in gethostname
> 9be4ed5 getopt_long_only: don't prefix-match long-options that match short ones
> 55a661f fix iconv buffer overflow converting to legacy JIS-based encodings
> 99f4237 fix iconv conversion to UTF-32 with implicit (big) endianness
> 165a1e3 fix iconv mapping of big5-hkscs characters that map to two unicode chars
> 029c622 fix output size handling for multi-unicode-char big5-hkscs characters
> 5c8e692 inet_ntop: do not compress single zeros in IPv6
> 8b8fb7f correctly handle non-matching symbols in dladdr
> 9cad27a fix writes outside buffer by ungetc after setvbuf
> b3fa0f2 fix regression in alignment of dirent structs produced by readdir
>
> Some fixes that would not be confirmed with just libc-test, but that
> needs more of a framework for covering multiple build configurations:
>
> a7c53e0 fix out-of-tree build of crt files with stack protector enabled
> e3c682a work around arm gcc's rejection of r7 asm constraints in thumb mode

You've just listed off a number of work tickets ;-) I'll set something
up and then show you the results - my server is limited in horsepower
though, and (in terms of actual hardware), I'm limited to x86_64,
arm64, arm32 (various arch versions), and a mips32.

C