4 ms·

C11 added a different set of safe string functions, although as an optional standard annex (Annex K). They have _s suffixes, e.g. strcpy_s(), and somewhat diffe

C11 added a different set of safe string functions, although as an optional standard annex (Annex K). They have _s suffixes, e.g. strcpy_s(), and somewhat different behavior. It seems unlikely that ISO would also add strlcpy() at this point, given that one set of "safe" functions is already (sort of) in the standard. But maybe POSIX could standardize it.

yuhong 12y ago
Which came directly from MS.
- BudVVeezer 12y ago
  Except that it was a collaborative effort that involved far more than just Microsoft, such as CERT, and the WG14 committee as a whole...
- dottrap 12y ago
  Too bad Microsoft Visual Studio refuses to get with the times and update their antiquated compiler from C89. They are now 2 standards and 25 years behind.
  - ygra 12y ago
    VS has a C++ compiler, not a C compiler. There is no getting with the times. That's like advocating that the Java compiler should get with the times and start compiling C++11. C and C++ are quite different languages, despite looking superficially the same. Think of it as a DVCS history that evolved into two very different branches at one point (C89) with the occasional feature branch of C merged into C++.
    - deleted 12y ago
      [deleted]
    - dottrap 12y ago
      Visual Studio is the only major C++ compiler that is inept at handling C. This is not unreasonable to expect proper C support and there is something terribly broken with Visual Studio in that they can't. Even Stroustrup has called for better compatibility with C.
      - _delirium 12y ago
        I don't see any particular reason you'd expect a C++ compiler to handle C, except the very specific part of C (largely C89) that is a proper subset of the C++ standards. They're very different languages at this point. gcc's C++ compiler doesn't handle C past C89 either; you can't use C99 features when compiling with g++. There is a separate C compiler that's part of the GNU Compiler Collection, but then there's also a Fortran and a Go compiler: gcc includes a lot of languages. MSVC++ doesn't; it's just a C++ compiler, not a Fortran or Java or C compiler. Linux norms are a bit more polyglot, so gcc is more polyglot than MSVC++ is. I personally like C, so it'd be nice if Microsoft shipped a C compiler in addition to a C++ compiler, but they've chosen not to. As a result, the "C" you can write is precisely the C that is also valid C++, and you can't use any features that aren't valid C++. If you really want there to be a language "C/C++" again that all C++ compilers can be expected to handle, you'd have to convince the C++ standards committee to add C99 or C11 features to the next C++1x.
ape4 12y ago
strcpy_s() doesn't appear to be in glibc. At least "man strcpy_s" give nothing on a Linux box.
- _delirium 12y ago
  Yes, glibc has so far chosen not to implement Annex K.

yuhong 12y ago

Which came directly from MS.

BudVVeezer 12y ago
Except that it was a collaborative effort that involved far more than just Microsoft, such as CERT, and the WG14 committee as a whole...
dottrap 12y ago
Too bad Microsoft Visual Studio refuses to get with the times and update their antiquated compiler from C89. They are now 2 standards and 25 years behind.
- ygra 12y ago
  VS has a C++ compiler, not a C compiler. There is no getting with the times. That's like advocating that the Java compiler should get with the times and start compiling C++11. C and C++ are quite different languages, despite looking superficially the same. Think of it as a DVCS history that evolved into two very different branches at one point (C89) with the occasional feature branch of C merged into C++.
  - deleted 12y ago
    [deleted]
  - dottrap 12y ago
    Visual Studio is the only major C++ compiler that is inept at handling C. This is not unreasonable to expect proper C support and there is something terribly broken with Visual Studio in that they can't. Even Stroustrup has called for better compatibility with C.
    - _delirium 12y ago
      I don't see any particular reason you'd expect a C++ compiler to handle C, except the very specific part of C (largely C89) that is a proper subset of the C++ standards. They're very different languages at this point. gcc's C++ compiler doesn't handle C past C89 either; you can't use C99 features when compiling with g++. There is a separate C compiler that's part of the GNU Compiler Collection, but then there's also a Fortran and a Go compiler: gcc includes a lot of languages. MSVC++ doesn't; it's just a C++ compiler, not a Fortran or Java or C compiler. Linux norms are a bit more polyglot, so gcc is more polyglot than MSVC++ is. I personally like C, so it'd be nice if Microsoft shipped a C compiler in addition to a C++ compiler, but they've chosen not to. As a result, the "C" you can write is precisely the C that is also valid C++, and you can't use any features that aren't valid C++. If you really want there to be a language "C/C++" again that all C++ compilers can be expected to handle, you'd have to convince the C++ standards committee to add C99 or C11 features to the next C++1x.

ape4 12y ago

strcpy_s() doesn't appear to be in glibc. At least "man strcpy_s" give nothing on a Linux box.

_delirium 12y ago
Yes, glibc has so far chosen not to implement Annex K.