Follow-up Comment #1, bug #40226 (project make): Second thought... I see now where the bug is coming from.
Some use cases for the stringlist imply it's handled as a null-terminated array: for (pp=output_sync_option->list; *pp; ++pp) Some others iterate up to idx: for (idx = 1; idx < sync_mutex->idx; idx++) For the second example, the list is initialized like this: sync_mutex->list = xmalloc (sizeof (char *)); sync_mutex->list[0] = xstrdup (hdl_string); sync_mutex->idx = 1; sync_mutex->max = 1; (copy/paste from the jobserver_fds code?) The problem is that decode_switches() assumes the first use case, but when sync_mutex ends up there, the fact that idx == max prevents the list to expand as the (sl->idx == sl->max - 1) condition is never met. So how to fix this best? For consistency, perhaps always ensure such a "list" null-terminated, and fix the initialization. That would also be in accordance with the struct stringlist comments. But there's also a simpler fix which would be to change the expansion check from (sl->idx == sl->max - 1) to (sl->idx >= sl->max - 1) so that it would also work for the case when they're both set to 1. Both solutions tested with success. (file #29345) _______________________________________________________ Additional Item Attachment: File name: 0001-Fix-initialization-of-sync_mutex-and-jobserver_fds-o.patch Size:1 KB _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?40226> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make