input byte-limited versions of output functions

[dankamongmen]

See #2754. @zhiayang and @neurocyte make a compelling case that the current putnstr family of functions aren't terribly useful, but something that limited the number of input bytes (similarly to all foonbar functions in the c library) might be.

Looking at it, i'm honestly unsure why i ever went with these definitions.

I don't want to simply change the definitions of the functions, so we'd need new symbols (annoying, as the putnstr ought follow the c library). I'm inclined to then deprecate the existing functions (leaving them in through at least 4.0), but let's look over the current demo/etc code to see if they're being used. Take a look at growlight and omphalos, as well. Any current uses run a good chance of being buggy due to a confused understanding of how these functions work IMHO.

What to call them?

I don't know if my main man @joseluis is still around, but we'd want rust wrappers (and C++, and Python). Probably not too difficult to put together based on what's already there.

[zhiayang]

i'm thinking we call these bois strn; it fits with the C functions (strncpy, strnlen, whatever) and all the current functions are nstr

that's kinda awfully confusing though LOL

[dankamongmen]

well, ideally the current set would go away sometime.

the thing i don't like about this is that they're likely to have the exact same signature, so there's no typing that saves you if you pick the wrong one. we might have to move an argument around,

if the current functions are totally worthless, as in we cannot come up with a good use for them, and no existing stuff uses them, i might be willing to just change them in place, although that's kinda canonically bad library design.

[zhiayang]

it might be enough to move arguments around (personally, I prefer putstrn over putnstr anyway xD)

the current functions seem to all take (size_t, const char*) -- we can do (const char*, size_t) for the new functions?

[dankamongmen]

everything takes its input data as the first parameter, though =[

[zhiayang]

everything takes its input data as the first parameter, though =[

not really sure what you mean by this?

[neurocyte]

For me it's nccell_load and ncstrwidth that are the most painfull. I would be really happy to see nccell_loadn and ncstrwidthn, but I'm really not too picky about the names.