1

I'm having trouble using strerrorlen_s in gcc 4.7.2 even though I defined __STDC_WANT_LIB_EXT1__ 1.

malat
  • 12,152
  • 13
  • 89
  • 158
clockley1
  • 464
  • 5
  • 16
  • What trouble are you having? – jim mcnamara Jul 31 '13 at 02:06
  • warning: implicit declaration of function ‘strerrorlen_s’ [-Wimplicit-function-declaration] /tmp/ccNK2h7T.o: In function `main': watchdogd.c:(.text+0xd7): undefined reference to `strerrorlen_s' collect2: error: ld returned 1 exit status – clockley1 Jul 31 '13 at 02:08
  • gcc 4.7.3: cc t.c -std=c11 t.c: In function ‘main’: t.c:8:5: warning: implicit declaration of function ‘strerrorlen_s’ [-Wimplicit-function-declaration] /tmp/ccHzZVKk.o:t.c:(.text+0x68): undefined reference to `strerrorlen_s' collect2: error: ld returned 1 exit status – jim mcnamara Jul 31 '13 at 02:15
  • I believe it is part of C11... someone close to what gcc is doing may know more. – jim mcnamara Jul 31 '13 at 02:17
  • It's part of C11 but it's optional, it was from a type-2 tech report, TR24731. My own viewpoint is that most of these functions are "safe" only if you use them properly. Which, surprisingly enough, is the same as the "unsafe" functions as well. Perhaps people needing this crutch may want to look into learning BASIC :-) – paxdiablo Jul 31 '13 at 02:22
  • An implementation that supports the optional library extensions will define `__STDC_LIB_EXT1__`. – Casey Jul 31 '13 at 02:29
  • Thanks I overlooked that. – clockley1 Jul 31 '13 at 02:36
  • library implentors seem to be reluctant to implement Annex K, though most of it can be achieved by relatively simple wrapper around existing functions. I have implemented these in P99, p99.gforge.inria.fr, maybe you should have a look. – Jens Gustedt Jul 31 '13 at 06:09
  • Note the question [Do you use the TR 24731 "safe" functions?](https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions) — and especially the part of my [answer](https://stackoverflow.com/a/373911/15168) where it is noted that there is a move to remove the Annex K functions from the next revision of the C standard (because they are universally unimplemented — Microsoft's version differs from the standard, and there are no other major implementations in widespread use). – Jonathan Leffler Aug 04 '17 at 06:43

2 Answers2

4

It's not in glib 2.13, at least under Debian, but I can't see why that would be different to any other system. A search for strerrorlen_s on the whole disk returns nothing.

It's also not listed in any of the release notes for 2.14 through the current 2.17 (searched for bounds, tr24731 and strerrorlen_s). It's not even mentioned on the 2.18 wiki page.

Keep in mind that the bounds checking interfaces are an optional feature of C11. Annex K details this, and implementations are not required to provide it at all.

K.2 Scope:

1/ This annex specifies a series of optional extensions that can be useful in the mitigation of security vulnerabilities in programs, and comprise new functions, macros, and types declared or defined in existing standard headers.

2/ An implementation that defines __STDC_LIB_EXT1__ shall conform to the specifications in this annex. Implementations that do not define __STDC_LIB_EXT1__ are not required to conform to these specifications.

It looks like there are actually no plans to support this feature in the core glibc at all. From a comment by Ulrich Drepper (admittedly March 2012) on whether support would be forthcoming:

Even the people who proposed them suggested them for fixing old code and not as the way forward. Such code belong in separate libraries which (a) take effort to use so that the functions become unused and (b) so that the library can be removed when the last offender is gone.

Similarly, from an LNW article around the same time:

There are no plans to add the C11 string bounds-checking interfaces from one of the annexes as there are questions about their usefulness even within the standards groups. That doesn't mean that those interfaces couldn't end up in the libc_ports tree, which provides a place for optional add-ons that aren't enabled by default. That would allow distributions or others to build those functions into their version of GLIBC.

Community
  • 1
  • 1
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
1
N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x

errno_t strerror_s(char *s, rsize_t maxsize, errno_t errnum);
size_t strerrorlen_s(errno_t errnum);
size_t strnlen_s(const char *s, size_t maxsize);

That's from my copy of the C11 standard - draft N1570. Maybe later versions of gcc have it... So we are not both crazy....

jim mcnamara
  • 16,005
  • 2
  • 34
  • 51