So @oni-link, what you're saying is that `maxlen` is just the length of `str` if `maxlen` is specified. Ergo if `maxlen >= 0`, `str` is a Pascal string? (not NUL-terminated). Which would indeed make it unsafe to call `STRLEN`. That means we should probably call `maxlen` something else. Am I misunderstanding?

> We would now only get problems, if maxlen would be bigger than the allocated range for str and str would not be NUL terminated. These problems are also present in the vim code, but we cannot detect them (cannot use STRLEN).

In the old code, if `maxlen` is bigger than the allocated range we would get problems anyhow, no? Whatever we do would read into unallocated memory. For correct functioning, `maxlen` would have to be <

In the new code, we have a different failure case: the code doesn't handle the case of a Pascal string, because it tries to take `STRLEN(str)` even if `maxlen` is specified.

> replace memcpy with xstpncpy.

Why would we do that? `xstpncpy` actually just calls `memcpy` anyway, if you already know the length you want. If the string is not NUL-terminated or `maxlen < strlen`, it acts exactly like `mempcpy(dst, src, maxlen)`. If the string IS NUL-terminated and `strlen < maxlen`, it acts like `memset(dst + strlen(src), 0, maxlen - strlen(src)); return mempcpy(dst, src, strlen(src));`, unnecesarily filling up the string with `'\0'`.

Note also that `stpncpy` doesn't necesarily NUL-terminate. Which is a shame. `xstrlcpy` is better in that regard.

> maxlen seems always not to be larger than the allocated range for str (see the start of the only possible call chain msg_outtrans_len_attr -> msg_puts_attr_len -> redir_write -> write_reg_contents for maxlen != -1).

I'm interested in just fixing this oversight instead of trying to accomodate the vim interface. I wonder how we can make this cleaner.