Picolibc – Libc for Embedded Systems

Re:Picolibc – Libc for Embedded Systems by saagarjha on Thursday October 03, 2019 @11:47PM (#21154614)

> glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around).

  snprintf(destination, sizeof(destination), "%s", source);

?

[ Parent | on HN ]

Re:Picolibc – Libc for Embedded Systems by wahern on Friday October 04, 2019 @12:05AM (#21154681)

snprintf(3) can fail with ENOMEM. In fact, at one point (not sure about now), glibc could fail with ENOMEM even for %s.[1]

The size argument is an int, not size_t, so there are arithmetic overflow problems.

The return value is also an int, creating underflow and overflow hazards, though the degree to which this is a problem, and the extent to which it's a feature, vary. Everybody has a different opinion about how truncation should be signaled, if at all.

[1] Because glibc snprintf uses (or at least used) its stdio FILE interfaces for implementing snprintf, and it conditionally uses malloc for initializing a temporary FILE object.

[ Parent | on HN ]

Re:Picolibc – Libc for Embedded Systems by saagarjha on Friday October 04, 2019 @12:13AM (#21154704)

You also missed the part where it's not necessarily self-evident what it does, or that it even fixes the issue ;)

[ Parent | on HN ]