Page MenuHomeFreeBSD

libc: Constify the getcap API
ClosedPublic

Authored by des on May 26 2026, 4:51 PM.
Tags
None
Referenced Files
F175047247: D57252.id178653.diff
Wed, Oct 7, 9:22 PM
Unknown Object (File)
Sun, Oct 4, 1:42 AM
Unknown Object (File)
Sat, Oct 3, 5:51 PM
Unknown Object (File)
Sat, Oct 3, 4:31 AM
Unknown Object (File)
Sat, Oct 3, 1:50 AM
Unknown Object (File)
Fri, Oct 2, 6:34 PM
Unknown Object (File)
Fri, Oct 2, 11:43 AM
Unknown Object (File)
Fri, Oct 2, 6:21 AM
Subscribers

Details

Summary

MFC after: 1 week
Inspired by: NetBSD

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

des requested review of this revision.May 26 2026, 4:51 PM

* (indicating pointers) should preferably be stuck onto the next token without intervening spaces everywhere, e.g.: const char * const *db_array => const char *const *db_array, because in a declaration the presence of the first * delimits the declarator list, which means that what is after the first * is specific to the variable being declared, and not to the next one in the list (that's IMO why that's the common practice for a single *).

Otherwise, looks good.

Outer (const char *) const is painful of course, since T** is invariant by T (I think this is the right term).

lib/libc/gen/disklabel.c
71

Is the cast for name needed after your changes?

libexec/getty/subr.c
57

Make dba static as well?

* (indicating pointers) should preferably be stuck onto the next token without intervening spaces everywhere, e.g.: const char * const *db_array => const char *const *db_array, because in a declaration the presence of the first * delimits the declarator list, which means that what is after the first * is specific to the variable being declared, and not to the next one in the list (that's IMO why that's the common practice for a single *).

The style I'm using here is the established style in our code base, see for instance fts(3), nv(9), strerror(3).

des marked 2 inline comments as done.Jun 4 2026, 9:40 PM
This revision is now accepted and ready to land.Jun 4 2026, 10:24 PM
This revision was automatically updated to reflect the committed changes.