Hi, our tool reports two recently introduced configuration-related problems:
Configurations with CONFIG_NC but without CONFIG_NC_110_COMPAT and without CONFIG_NC_EXTRA: CC networking/nc.o networking/nc.c: In function ‘nc_main’: networking/nc.c:232: error: subscripted value is neither array nor pointer Configurations with CONFIG_MDEV but without CONFIG_FEATURE_MDEV_CONF CC util-linux/mdev.o util-linux/mdev.c: In function ‘make_device’: util-linux/mdev.c:650: error: ‘struct globals’ has no member named ‘parser’ util-linux/mdev.c:650: error: ‘struct globals’ has no member named ‘parser’ Best regards, Christian On 04/20/2012 08:58 AM, Denys Vlasenko wrote: > 2012/4/19 Christian Kästner <christian.kaest...@uni-marburg.de>: >> Hi, >> In a research setting, I've been working on a tool TypeChef that can >> detect compilation errors over all compile-time configurations of a >> software. The tool is intended as a lint-like of tool that reports >> compilation errors and the configurations in occurs in. Essentially it >> predicts with which preprocessor flags the code will not compile. >> >> Among others, we have experimented with that tool on Busybox. In the >> current code base, we find the two following problems: >> >> * networking/httpd.c won't compile in configurations with CONFIG_HTTPD >> and CONFIG_FEATURE_HTTPD_BASIC_AUTH, without >> CONFIG_FEATURE_HTTPD_AUTH_MD5 and with CONFIG_PAM (struct pam_userinfo >> not defined) >> >> * shell/hush.c won't compile in configurations with CONFIG_HUSH and >> CONFIG_FEATURE_EDITING_SAVE_ON_EXIT but without CONFIG_HUSH_INTERACTIVE >> and without CONFIG_FEATURE_EDITING (field line_input_state unknown in >> globals) > > Fixed both, and a few more on top of them. Thanks! > >> My question is to what degree you as community are interested in such >> feedback? Unfortunately, we don't have the capacity to investigate and >> submit actual patches every time we could identify a problem. Would it >> be still helpful to send just (automatic) error reports, similar to the >> ones above? > > Yes, it would be helpful. > >> Finally, we were surprised that we found essentially no compile-time >> problems despite the large configuration space (we have found no >> compilation errors in released code). Do you have a process to prevent >> or detect those kinds of problems for releases, such as randomized testing? > > We have scripts/randomtest[.loop] which can be used to build > randomly-configured busybox and run testsuite on it. > > I use it for pre-release testing. > _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
