tags:

views:

646

answers:

7

What's the best one-stop-shop "safe" C library solution on the Mac? I use quotes on "safe"/"unsafe" because there is much debate as to the benefits of certain Standard Library functions or their putatively improved alternatives.

Many traditional Standard C Library functions (e.g., vfprintf) are considered to be unsafe due to the potential for buffer overflow or other security problems.

On Windows, the Microsoft C/C++ compilers provide the "_s" functions (e.g., vfprintf_s) as a safer alternative to the standard library calls. These functions are not drop-in replacements since they have the different signatures necessary to provide additional safety information (e.g., buffer length). They also provide other features such as invalid format string detection, different file security, etc. As far as I know, this implementation is not available on the Mac.

Does Apple (or a third party) provide anything similar for use with GCC on OSX?

In particular, I'm looking for "safe" implementations of at least the following functions:

fopen vfprintf vsprintf sprintf strncpy strcpy strcat

Please note: This question is about the Mac. I am NOT asking for your opinions about Microsoft's implementation (unless it's available on the Mac.) Although some of these functions might be easy to write myself, not all are. I am NOT asking how to write these myself. I'm NOT asking for tips on how to use STL classes to do this. I'm NOT asking how to turn off warnings. My particular needs are very specific. I'm trying to identify a best-practice Mac API that is as similar as possible to the traditional C library calls while adding safety. Of course a portable implementation that works on Mac and Windows (and other operating systems) would be even better.

+5  A: 

Instead sprintf and vsprintf, you want to use:

snprintf(buffer, buffer_size, fmt_string, args, ...);
vsnprintf(buffer, buffer_size, fmt_string, valist);

Instead of strcpy, strncpy, strcat and strncat you want to us:

strlcpy(dest, src, dest_size);
strlcat(dest, src, dest_size);

There is one important way that the strn functions can not be replaced by the strl functions. If you want to copy non-0 terminated strings, the strn functions allow you to do that by setting the length to the smaller value of the amount of copy and the size of the destination buffer. The strl functions do not do that and only work when the source string is 0 terminated.

Not sure how fopen or vfprintf are considered unsafe.

R Samuel Klatchko
vfprintf() is unsafe because it supports the '%n' directive (to report the number of bytes written at the time when the directive is processed). This was a funny (bad?) move on the C89 standardization process - it requires an output parameter (pointer to int) in `printf()` et al. That much is unsafe - but the rest isn't.
Jonathan Leffler
+3  A: 

Since OSX's userland is based on FreeBSD, you do have some nicer functions like strlcpy and strlcat.

Nikolai N Fetissov
+9  A: 

First of all, print the documentation about "safe/unsafe" functions from MSDN and burn it!

fopen

Is as safe as fopen_s... Uless you are idiot and assume that returned pointer is not NULL, or provide NULL as input parameter.

vfprintf vsprintf sprintf 

Just MS do not support C99, use snprintf family.

 strncpy

Is perfectly safe if you read the manual

strcpy strcat

Use strncpy and strncat and read specifications. (i.e. strncpy may be not null terminated)

So... once again:

Print the documentation about "safe/unsafe" functions from MSDN and burn it!

Artyom
strncpy / strncat are safe but are a pain to use correctly. strncpy requires the caller to add the 0 terminator. strncat requires the user to calculate how much to copy, not the size of the destination buffer.
R Samuel Klatchko
Note that Microsoft's vsnprintf() cannot be standard (C99) compliant because the C99 definition requires vsnprintf() to add a terminating null unless the length of the buffer is zero (and that has a special meaning). I presume MS knows what it means when it says that its vsnprintf() does not always add the terminal null, but that just means that MS (probably) implemented it before the standard canonized the correct behaviour, and then felt unable to risk changing the erroneous definition (even though it is hard to see any working code breaking as a result of the change).
Jonathan Leffler
@Artyom, Thanks for your answer. You may safely assume that I AM an idiot. In particular, you can bet that I will eventually err with any function that is "safe if I read the manual".
jwfearn
@jwfearn -- the point is that MS created their own "safe" functions instead of adopting safe functions of C99. For example, fopen_s is total "crap", sprintf_s as well - use snprintf. And so on. Yes, strncpy and strncat are tricy but still, it is much better to stay withing the standard then... Don't beleve everything you read about "unsafe-funtions"
Artyom
Actually, TR24731 post-dates the equivalent functions from MS - MS implemented something, then submitted their system to the Standard C committee. What was 'standardized' (to the extent it is standardized; it is a tech report at the moment) was different from the MS proposal.
Jonathan Leffler
+2  A: 

The C standard already has a set of "Safe" version of these functions.
(For a particular definition of the term safe)

The snprintf() (and family) provide the safety features you are looking for. Buffer overflow checking.
The gcc compiler in addition does format string validation (but better than MS because the validation is done at compile time).

fopen()             Not sure how you make that safer?
vfprintf            --  These are low level functions
vsprintf            --  These are low level functions
sprintf             snprintf
strncpy             Already the safe version
strcpy              strncpy
strcat              strncat
Martin York
My understanding re: fopen is that the "standard" version is specified to use default security rules which may not match the "safe" defaults of the host OS...or something like that. Not that it's a buffer overflow issue. I could be wrong. I included it in my list since MSVC provides an fopen_s function.
jwfearn
strncpy() has to be used very carefully to be safe - it does not null terminate when the source is too long for the destination. It's padding property (zero padding to full length) is sometimes a handicap, especially if you have a 20 KB buffer but are mostly schlepping 50 bytes strings around.
Jonathan Leffler
@jwfearn: in TR24731, the main difference between standard fopen() and fopen_s() is the addition of a flag, 'u'. Quoting: To the extent that the underlying system supports the concepts, files opened for writing shall be opened with exclusive (also known as non-shared) access. If the file is beingcreated, and the first character of the mode string is not ’u’, to the extent that the underlying system supports it, the file shall have a file permission that prevents otherusers on the system from accessing the file. [...]
Jonathan Leffler
+2  A: 

See also: SO 327980.

The Standard C committee has created a technical report, TR 24731-1, in part at Microsoft's encouragement (I believe). It standardizes the interfaces to the various functions such as vsnprintf_s(). Sadly, however, the interface defined by the standard is incompatible with the interface defined by Microsoft, thus rendering the standard largely irrelevant.

For example, TR 24731-1 says the interface to vsnprintf_s() is:

#define _ _STDC_WANT_LIB_EXT1_ _ 1
#include <stdarg.h>
#include <stdio.h>
int vsnprintf_s(char * restrict s, rsize_t n,
                const char * restrict format, va_list arg);

Unfortunately, MSDN says the interface to vsnprintf_s() is:

int vsnprintf_s(
   char *buffer,
   size_t sizeOfBuffer,
   size_t count,
   const char *format,
   va_list argptr 
);

Parameters

  • buffer - Storage location for output.
  • sizeOfBuffer - The size of the buffer for output.
  • count - Maximum number of characters to write (not including the terminating null), or _TRUNCATE.
  • format - Format specification.
  • argptr - Pointer to list of arguments.

Note that this is not simply a matter of type mapping: the number of fixed arguments is different, and therefore irreconcilable. It is also unclear to me (and presumably to the standards committee too) what benefit there is to having both 'sizeOfBuffer' and 'count'; it looks like the same information twice (or, at least, code will commonly be written with the same value for both parameters).

Jonathan Leffler
@Jonathan Leffler: do you know if these APIs are available on the Mac?
jwfearn
They are not in the main system library - /usr/lib/libSystem.B.dylib. I haven't checked every dylib on the machine, but I suspect they are conspicuous by their absence, here and on most Unix-based machines. Someone did create the safe library for the string routines about, oh, 6 months or so ago; you might be able to find that on the web (ask me if you can't).
Jonathan Leffler
I did a thorough search (`find / -name '*.dylib' -print0 | xargs -0 nm -og | grep '_s$'`) and didn't find any of the TR 24731 safe functions. There were a number of functions that ended '_s', but none that are relevant.
Jonathan Leffler
A: 

SUMMARY: on Mac, there are several APIs and compiler options that provide safer alternatives to C Standard Library functions. Here are some of them compared with Microsoft's "safe" APIs:

   C        MSVC      PROVIDERS  SOLUTION
---------------------------------------------------------------------------------
fopen     fopen_s     C          none, assume fopen is safe
vfprintf  vfprintf_s  GCC        GCC_WARN_TYPECHECK_CALLS_TO_PRINTF(1)
vsprintf  vsprintf_s  GCC, C99   GCC_WARN_TYPECHECK_CALLS_TO_PRINTF, vsnprintf(2)
sprintf   sprintf_s   GCC, C99   GCC_WARN_TYPECHECK_CALLS_TO_PRINTF, snprintf(3)
strncpy   strncpy_s   BSD        strlcpy(4)
strcpy    strcpy_s    BSD        strlcpy
strcat    strcat_s    BSD        strlcat(5)

(1) GCC_WARN_TYPECHECK_CALLS_TO_PRINTF is an XCode configuration option which corresponds to the GCC command-line option -Wformat. This option produces compiler warnings of disagreement between argument types and static format strings. There are a variety of other options to control GCC's treatment of format strings. You can even use GCC's format function attribute to enable format string checking on your own functions.

(2) vsnprintf and (3) snprintf are from the C99 version of the C Standard Library (available in GCC on Mac but not in MSVC on Windows).

(4) strlcpy and (5) strlcat are BSD library functions, available on Mac.

jwfearn
+1  A: 

Google Summer of Code 2010: OpenAfs and Google are sponsoring a port of Microsoft's String Safe library. See http://www.openafs.org/pages/gsoc.html.

Jeffrey Walton