Page MenuHomeFreeBSD

stand: use snprintf here
ClosedPublic

Authored by imp on Apr 30 2022, 2:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 16, 4:44 AM
Unknown Object (File)
Sat, Nov 16, 3:55 AM
Unknown Object (File)
Sat, Nov 16, 1:47 AM
Unknown Object (File)
Oct 9 2024, 11:05 AM
Unknown Object (File)
Oct 9 2024, 11:04 AM
Unknown Object (File)
Oct 9 2024, 11:04 AM
Unknown Object (File)
Oct 9 2024, 10:18 AM
Unknown Object (File)
Oct 8 2024, 1:50 AM
Subscribers

Details

Summary

This code was written prior to snprintf being in the then libstand (now
libsa). Since we have it, use it for extra safety. The code already
tries to be safe, but since we have snprintf as well, the added layer of
protection will suffice. The current code reserves 16 bytes (plus a NUL)
at the end for worst case of inet_ntoa, which is still a little
pessimal, but safe from overflow.

Sponsored by: Netflix

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 45442
Build 42330: arc lint + arc unit

Event Timeline

imp requested review of this revision.Apr 30 2022, 2:00 PM

I believe the new code is the same safety as the old if there's no bugs, and safer if there are bugs.
Discuss and/or prove me wrong.

There is this nagging question however - should we check the return value from snprintf (like in this last instance). We do know those strings should fit (normally), but if there is non normal case of memory corruption...

This revision is now accepted and ready to land.Apr 30 2022, 2:13 PM

There is this nagging question however - should we check the return value from snprintf (like in this last instance). We do know those strings should fit (normally), but if there is non normal case of memory corruption...

You're not wrong. However, we have hundreds of calls to snprintf in stand, and we check the return value of none of them....

Honestly, though, this code is crying out for sbuf. We'd be much better off using sbuf here which takes care of all that nonsense. We're no longer so massively constrained on how much memory we can use that a malloc or two to get to the right buffer size would be a problem like it was in the late 80s and early 90s when much of this code was written.

This revision was automatically updated to reflect the committed changes.