OSDev.org

I'm attempting to implement my own libc along with my OS. Is it considered bad form to put non-standard function declarations into the standard libc headers?

Eg: adding some convenience string function into <string.h>, rather than creating a <stringutils.h> or something?

If you would keep it separate, would you also compile these things to their own binary, rather than linking it into my libc.a?

There may be no 'right answer' to this, but I'm interested in opinions.

Twicetimes wrote:I'm attempting to implement my own libc along with my OS. Is it considered bad form to put non-standard function declarations into the standard libc headers?

Eg: adding some convenience string function into <string.h>, rather than creating a <stringutils.h> or something?

If you would keep it separate, would you also compile these things to their own binary, rather than linking it into my libc.a?

There may be no 'right answer' to this, but I'm interested in opinions.

There is a right answer. The contents of the varous libc headers are defined by the specifications that you support. If your libc is C standard compliant or Posix compliant you must follow those standards which usually means that you may not pollute the namespace with non-compliant features. The simple solution is to define a macro like '__USE_MYOS and surround your non-compliant declarations with ifdefs. You must also be careful that non-conforming function names are not 'dragged in' by conforming ones. For example, make sure that you don't build implement strcpy on top of your own stringcopy because the linker will drag in stringcopy and it may conflict with a function the user is writing. Keep extern functions in separate files, make sure internal functions are static or in the reserved namespace and make sure that libc functions only call other functions that are defined in the same standard.

Makes sense, thanks.