Do you use the TR 24731 'safe' functions in your C code?

Question

The ISO C committee (ISO/IEC JTC1/SC21/WG14) has published TR 24731-1 and is working on TR 24731-2 (the second part is still under development). From the web site:

---

TR 24731-1: Extensions to the C Library Part I: Bounds-checking interfaces

WG14 is working on a TR on safer C library functions. This TR is oriented towards modifying existing programs, often by adding an extra parameter with the buffer length. The latest draft is in document N1225. A rationale is in document N1173. This is to become a Technical Report type 2.

TR 24731-2: Extensions to the C Library - Part II: Dynamic allocation functions

WG14 is working on a TR on safer C library functions. This TR is oriented towards new programs using dynamic allocation instead of an extra parameter for the buffer length. The latest draft is in document N1337. This is to become a Technical Report type 2.

---

(Documentation available for download at the site cited earlier.)

Questions

• Do you use a library or compiler with support for the TR24731-1 functions?
• If so, which compiler or library and on which platform(s)?
• Did you uncover any bugs as a result of fixing your code to use these functions?
• Which functions provide the most value?
• Are there any that provide no value or negative value?
• Are you planning to use the library in the future?
• Are you tracking the TR24731-2 work at all?

Answer 1

I have been a vocal critic of these TRs since their inception (when it was a single TR) and would never use them in any of my software. They mask symptoms instead of addressing causes and it is my opinion that if anything they will have a negative impact on software design as they provide a false sense of security instead of promoting existing practices that can accomplish the same goals much more effectively. I am not alone, in fact I am not aware of a single major proponent outside of the committee developing these TRs.

I use glibc and as such know that I will be spared having to deal with this nonsense, as Ulrich Drepper, lead maintainer for glibc, said about the topic:

The proposed safe(r) ISO C library fails to address to issue completely. ... Proposing to make the life of a programmer even harder is not going to help. But this is exactly what is proposed. ... They all require more work to be done or are just plain silly.

He goes on to detail problems with a number of the proposed functions and has elsewhere indicated that glibc would never support this.

The Austin Group (responsible for maintaining POSIX) provided a very critical review of the TR, their comments and the committee responses available here. The Austin Group review does a very good job detailing many of the problems with the TR so I won't go into individual details here.

So the bottom line is: I don't use an implementation that supports or will support this, I don't plan on ever using these functions, and I see no positive value in the TR. I personally believe that the only reason the TR is still alive in any form is because it is being pushed hard by Microsoft who has recently proved very capable of getting things rammed though standards committees despite wide-spread opposition. If these functions are ever standardized I don't think they will ever become widely used as the proposal has been around for a few years now and has failed to garner any real community support.

Answer 2

I like Robert's answer, but I also have some views on the questions I raised.

• Do you use a library or compiler with support for the TR24731-1 functions?

No, I don't.

• If so, which compiler or library and on which platform(s)?

I believe the functions are provided by MS Visual Studio (MS VC++ 2008 Edition, for example), and there are warnings to encourage you to use them.

• Did you uncover any bugs as a result of fixing your code to use these functions?

Not yet. And I don't expect to uncover many in my code. Some of the other code I work with - maybe. But I've yet to be convinced.

• Which functions provide the most value?

I like the fact that the printf_s() family of functions do not accept the '%n' format specifier.

• Are there any that provide no value or negative value?

The tmpfile_s() and tmpnam_s() functions are a horrible disappointment. They really needed to work more like mkstemp() which both creates the file and opens it to ensure there is no TOCTOU (time-of-check, time-of-use) vulnerability. As it stands, those two provide very little value.

I also think that strerrorlen_s() provides very little value.

• Are you planning to use the library in the future?

I am in two minds about it. I started work on a library that would implement the capabilities of TR 24731 over a standard C library, but got caught by the amount of unit testing needed to demonstrate that it is working correctly. I'm not sure whether to continue that. I have some code that I want to port to Windows (mainly out of a perverse desire to provide support on all platforms - it's been working on Unix derivatives for a couple of decades now). Unfortunately, to get it to compile without warnings from the MSVC compilers, I have to plaster the code with stuff to prevent MSVC wittering about me using the perfectly reliable (when carefully used) standard C library functions. And that is not appetizing. It is bad enough that I have to deal with most of two decades worth of a system that has developed over that period; having to deal with someone's idea of fun (making people adopt TR 24731 when they don't need to) is annoying. That was partly why I started the library development - to allow me to use the same interfaces on Unix and Windows. But I'm not sure what I'll do from here.

• Are you tracking the TR24731-2 work at all?

I'd not been tracking it until I went to the standards site while collecting the data for the question. The asprintf() and vasprintf() functions are probably valuable; I'd use those. I'm not certain about the memory stream I/O functions. Having strdup() standardized at the C level would be a huge step forward. This seems less controversial to me than the part 1 (bounds checking) interfaces.

Overall, I'm not convinced by part 1 'Bounds-Checking Interfaces'. The material in the draft of part 2 'Dynamic Allocation Functions' is better.

If it were up to me, I'd move somewhat along the lines of part 1, but I'd also revised the interfaces in the C99 standard C library that return a char * to the start of the string (e.g. strcpy() and strcat()) so that instead of returning a pointer to the start, they'd return a pointer to the null byte at the end of the new string. This would make some common idioms (such as repeatedly concatenating strings onto the end of another) more efficient because it would make it trivial to avoid the quadratic behaviour exhibited by code that repeatedly uses strcat(). The replacements would all ensure null-termination of output strings, like the TR24731 versions do. I'm not wholly averse to the idea of the checking interface, nor to the exception handling functions. It's a tricky business.

Answer 3

Do you use a library or compiler with support for the TR24731-1 functions? If so, which compiler or library and on which platform(s)?

Yes, Visual Studio 2005 & 2008 (for Win32 development obviously).

Did you uncover any bugs as a result of fixing your code to use these functions?

Sort of.... I wrote my own library of safe functions (only about 15 that we use frequently) that would be used on multiple platforms -- Linux, Windows, VxWorks, INtime, RTX, and uItron. The reason for creating the safe functions were:

• We had encountered a large number of bugs due to improper use of the standard C functions.
• I was not satisfied with the information passed into or returned from the TR functions, or in some cases, their POSIX alternatives.

Once the functions were written, more bugs were discovered. So yes, there was value in using the functions.

Which functions provide the most value?

Safer versions of vsnprintf, strncpy, strncat.

Are there any that provide no value or negative value?

fopen_s and similar functions add very little value for me personally. I'm OK if fopen returns NULL. You should always check the return value of the function. If someone ignores the return value of fopen, what is going to make them check the return value of fopen_s? I understand that fopen_s will return more specific error information which can be useful in some contexts. But for what I'm working on, this doesn't matter.

Are you planning to use the library in the future?

We are using it now -- inside our own "safe" library.

Are you tracking the TR24731-2 work at all?

No.