ac05de1788
It's currently unclear to me how this could have worked previously; \n here is not a literal newline but actual '\' 'n', and was getting passed to the underlying regex engine as such. regex(3) does not translate this to a newline, and this became an error because we don't really allow escaping of arbitrary ordinary characters anymore. Run the pattern strings through printf to make sure we're dealing with real newlines before passing them through to atf_check, which ultimately feeds them directly to regcomp(3). This fix is different than that will be needed for sed, in that this is the proper way to inject newlines into search strings as long as regex(3) won't combine \ + n as folks might expect. Reported by: Jenkins via lwhsu MFC after: 1 week |
||
|---|---|---|
| .. | ||
| Bflag_C.out | ||
| Bflag_D.out | ||
| Bflag_F.out | ||
| diff_test.sh | ||
| group-format.out | ||
| header_ns.out | ||
| header.out | ||
| ifdef.out | ||
| input1.in | ||
| input2.in | ||
| input_c1.in | ||
| input_c2.in | ||
| Makefile | ||
| Makefile.depend | ||
| simple_b.out | ||
| simple_e.out | ||
| simple_i.out | ||
| simple_n.out | ||
| simple_p.out | ||
| simple_u.out | ||
| simple_w.out | ||
| simple.out | ||
| unified_9999.out | ||
| unified_c9999.out | ||
| unified_p.out | ||