<div dir="ltr"><div>The problem is, as far as NUT code is concerned, we are using tolower(), isalpha() etc. which may well be real functions in some libraries and macros with bit-shift magic or arrays on others...</div><div>This is hard to catch without actually running builds on dozens of platforms :)</div><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Mar 31, 2025 at 4:13 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>> writes:<br>
<br>
> It seems bumping all those buffers to [NUT_PATH_MAX+1]` (for the NUL ending<br>
> char) helps, and seems a reasonable thing to do safely.<br>
<br>
Sure, if that helps that really seems sensible.<br>
<br>
> the char subscripts only with CLANG (13), on my dormant NetBSD 9.2 VM.<br>
<br>
NetBSD is louder about it, but ctype(3) is really hard to use correctly<br>
and risks undefined behavior.<br>
</blockquote></div>