Linking problems with out-of-line definitions for checkedc_extensions.h

[secure-sw-dev-bot]

This issue was copied from checkedc/checkedc#449

---

Some linking problems can occur when using the functions declared in checkedc_extensions.h:

• Since strncmp_array_ptr is declared extern inline, it will generate an out-of-line definition in every translation unit that includes checkedc_extensions.h. This causes a link error if multiple translation units include checkedc_extensions.h.
• snprintf_array_ptr simply isn't defined anywhere that I can see.

It seems that the fundamental problem of providing out-of-line definitions for Checked C extensions has not been solved. Some potential solutions:

1. Use inline rather than extern inline (so an out-of-line definition is never generated) and use __attribute__(always_inline). This fails if the user takes the address of the function and maybe in some other cases.

2. Use extern inline but declare the function as __attribute__(weak) or similar so that the linker deduplicates out-of-line definitions without error. (I think this is the same mechanism used to deduplicate C++ template instantiations.)

3. Use static inline so that every translation unit that makes a non-inlinable call to the function generates its own out-of-line copy but these copies don't conflict at link time. This increases code size and might cause some problems in some scenarios such as setting a breakpoint in all copies during debugging.

4. Omit the function body and use asm(strncmp) or similar to cause a call to strncmp_array_ptr to be redirected to strncmp by the compiler. This is probably the cleanest solution when it works, but it might confuse some program analyses or other development tools.

5. Omit the function body and use __attribute__(weakref) (documentation) or similar. I'm having a hard time understanding the documentation, but it sounds like this might have a similar effect as asm.

6. Put the out-of-line definition in a separate library that the user's program links against like any other library. Adding the library to linker commands could be manual, or automatic like it is for the standard C library.

7. Bite the bullet and add support to the Checked C compiler for multiple different bounds-safe interfaces of the same function. This is probably the most work but would give a nice user experience since the user doesn't have to use a different function name. Since the compiler already has code to merge a fully unchecked function declaration and a declaration of the same function with bounds-safe interfaces, I suspect it might not be hard to extend its data structures to support a list of bounds-safe interfaces for the same function; I haven't looked at the implementation.

   One concern is that if the call site doesn't indicate by some means which interface is intended and the call doesn't satisfy the requirements of any of the interfaces, it could be hard to generate diagnostics sufficient to help a user (especially a user new to Checked C) successfully troubleshoot the problem.

One thing worth considering: In the future, you may wish to add helper functions that are commonly needed by Checked C code but have different semantics from any standard C function, such as the xstrbcpy, xstrbcat, and xsbprintf string manipulation functions that we (CCI) defined in some of our own ports. If you adopt a solution for multiple-interface functions that supports a custom function definition (1, 2, 3, or 6 above), then the same solution could be used for custom helper functions. But you may decide that it's more important to use a solution for multiple-interface functions that doesn't involve them having their own definitions, trivial as they might be.

[secure-sw-dev-bot]

Comment from @sulekhark:

We prefer to use options 1 or 3 for now - I have updated checkedc_extensions.h accordingly. We may consider option 6 in the future but only if there is a clear demand for it.

[secure-sw-dev-bot]

Comment from @sulekhark:

Fixed by PR #456.