mbox series

[v5,0/4] stdio-common: Add test for vfscanf with matches longer than INT_MAX [BZ #27650]

Message ID alpine.DEB.2.21.2407121331540.38148@angie.orcam.me.uk
Headers show
Series stdio-common: Add test for vfscanf with matches longer than INT_MAX [BZ #27650] | expand

Message

Maciej W. Rozycki July 12, 2024, 8:48 p.m. UTC 
Hi,

 This update supersedes v4 following failure reports from CI, caused by 
the definition of the FAIL macro in support/check.h clashing with local 
definitions by the same name across numerous existing test cases.

 As it happens some of these test cases define their FAIL macro almost if 
not exactly the same as facilities already provided by support/check.h, or 
by the new FAIL macro introduced by this patch series.  Therefore this new 
revision rewrites those test cases in terms of support/check.h, removing 
their local FAIL macro definitions.  See individual change descriptions 
and discussions for details.

 This has been verified with the `powerpc64le-linux-gnu' native system and 
then the same host, and then the `riscv64-linux-gnu' and `mips-linux-gnu' 
targets, by running the full regression testsuite rather than just the new 
test case as I did previously.

 For the record verification with the `alpha-linux-gnu' target did not 
succeed due to problems with the target itself.  Testing first became 
swamped for several days in locale generation triggering the OOM killer 
repeatedly after several hours each time (despite the data segment limit 
set well below the amount of RAM available).  And then finally the machine 
stopped responding but to the Magic SysRq feature on the serial console, 
so all the subsequent test cases have failed due to the inability to 
access the remote target for execution.

 By the look of it I suspect a problem with the Linux kernel network 
driver for the backup onboard 10BASE-T Ethernet interface currently used 
due to an ongoing networking failure in my lab, so I may be able to 
complete glibc regression testing after all once I have the networking 
failure sorted later this year (the usual FDDI interface is also faster).  
I may not be able to add RAM, currently at 160MiB, to the machine as 
suitable modules are now hard to source, and I feel like adding swap space 
is not going to help much in terms of performance.

 Anyway, I only mentioned it in reference to my earlier `alpha-linux-gnu' 
testing and it should not matter for the changes in this patch series, as 
there is nothing Alpha-specific there and results are looking good for the 
remaining targets.

 Any further questions, comments or concerns?  Otherwise OK to apply?

  Maciej