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
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-make
