AddressSanitizer: negative-size-param in decompose_paths about yash HOT 6 CLOSED

Sure. Closing this issue then. Thanks for taking a look!

from yash.

Thanks for the report, but I have difficulty interpreting the message from the address sanitizer.
The third parameter to the wcsnrtombs function is of type size_t, which is an unsigned integer and can't be negative.
The parameter specifies the maximum number of characters to be converted, which is irrelevant to the actual size of arrays involved. Maybe the sanitizer is incorrectly configured to perform some check about this parameter?

PS: To print a size_t value, you should be using %zu rather than %ld.

from yash.

You are right. After further investigation, this seems to be a bug in AddressSanitizer. google/sanitizers#1524

However, this makes me wonder if wcsrtombs should be used instead when size is not specified. We don't have a buffer as big as Size_max anyway, and size_t len is still there to prevent buffer overflow. Why use such a large number here?

from yash.

Defining sb_wcscat as a special case of sb_wcsncat is much simpler than defining them as separate functions that are very similar but differ only in one line that calls either wcsrtombs or wcsnrtombs.

sb_wcscat is defined as: https://github.com/magicant/yash/blob/2e02670ad531ea8ac445217ce70d32915c736709/strbuf.h#L322C1-L328

from yash.

Defining sb_wcscat as a special case of sb_wcsncat is much simpler than defining them as separate functions that are very similar but differ only in one line that calls either wcsrtombs or wcsnrtombs.

Yes, but we already have sb_wcscat and malloc_wcstombs for systems without wcsnrtombs anyway. Could they be enabled on all systems?

from yash.

Hmm, I don't want to bloat the binary just to make the misbehaving analyzer happy.

from yash.