2

I'm trying the below code to see if the optional string functions in C are supported (I've got Mac OS X El Capitan and XCode installed)...

#include <stdio.h>

int main(void)
{
  #if defined __STDC_LIB_EXT1__
    printf("Optional functions are defined.\n");
  #else
    printf("Optional functions are not defined.\n");
  #endif

  return 0;
}

...but it suggests they aren't.

I've tried all the different compilers I have from XCode (cc, gcc, llvm-gcc, clang).

I've also tried brew install gcc assuming that the GNU C compiler would give me these extra functions, but it doesn't.

Is there a way to simply install a C11 compatible compiler on Mac OS that'll give me these additional (i.e. safe) string functions.

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
Integralist
  • 5,899
  • 5
  • 25
  • 42
  • Possible duplicate of [Mac solution for "safe" alternatives to "unsafe" C/C++ Standard Library functions?](http://stackoverflow.com/questions/2169016/mac-solution-for-safe-alternatives-to-unsafe-c-c-standard-library-function) – Laser Nov 28 '16 at 06:36

2 Answers2

1

Summary: You won't get it to work. There are better ways to make sure your code is correct. For now, use the address sanitizer instead.

Also known as "Annex K" of the C11 standard or TR 24731, these functions are not widely implemented. The only commonly available implementation is part of Microsoft Visual Studio, other common C implementations have rejected (explicitly, even) the functionality in annex K. So, while annex K is technically part of the standard, for practical purposes it should be treated as a Microsoft-specific extension.

See Field Experience With Annex K — Bounds Checking Interfaces (document N1967) for more information. According to this report, there are only four implementations of annex K, two are for Windows, one is considered "very incomplete" and the remaining one is "unsuitable for production use without considerable changes."

However, the argument that these string functions are "safe" is a bit misleading. These functions merely add bounds checking, which only works if the functions are called correctly—but then again, the "non-safe" functions only work if they are called correctly too. From the report cited above,

Despite more than a decade since the original proposal and nearly ten years since the ratification of ISO/IEC TR 24731-1:2007, and almost five years since the introduction of the Bounds checking interfaces into the C standard, no viable conforming implementations has emerged. The APIs continue to be controversial and requests for implementation continue to be rejected by implementers.

The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. More effective and less intrusive approaches have become commonplace and are often preferred by users and security experts alike.

Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed.

I suggest using the address sanitizer as an alternative.

Do not use strncpy, strncat or the like as "safe" functions, they're not designed to do that and they are not drop-in replacements for strcpy, strcat, etc., unlike strcpy_s, strcat_s, which are drop-in replacements.

Community
  • 1
  • 1
Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • Note that the cited report is totally wrong. They simply don't know about 'viable conforming implementations', and their criticism on existing implementations (mainly Microsoft) is also flawed. They cite the Annex K callbacks as risky, but they are much less risky than their own ENV hooks. The address sanitizers, fortifiers and static tools are by far not a viable replacements for the secure extensions. They either rely only on compile-time or run-time checks, a proper implementation does both, fast and securely. – rurban Dec 20 '18 at 10:35
  • 1
    @rurban: You say it is wrong, but can you provide reasoning to support that claim? It's a little frustrating that you seem to have knowledge about annex K that you are unwilling to share. – Dietrich Epp Dec 20 '18 at 17:53
  • Unwilling to share? I wrote besides the implementation also extensive documentation on those issues, besides constantly teaching about it. Maybe look it up. – rurban Dec 22 '18 at 09:57
  • 1
    @rurban: If you want to make corrections to my answer, give me the evidence and reasoning to support your changes. I’m not going to cite you as an authoritative source, I simply don’t know who you are. – Dietrich Epp Dec 22 '18 at 14:50
0

If you are not using Windows or Embarcadero you need to use the external safeclib: https://github.com/rurban/safeclib/releases

No other libc's comes with the safe C11 Annex K extensions. For an overview of the various libc quirks regarding this see https://rurban.github.io/safeclib/doc/safec-3.3/d1/dae/md_doc_libc-overview.html

rurban
  • 4,025
  • 24
  • 27