Prev: Newbie question: Need for header file when linking to static library
Next: using CList as a base class in an extension DLL
From: Joseph M. Newcomer on 10 Nov 2009 19:17
I find the fopen_s a truly weird mechanism, since there was nothing that could cause a
"buffer overflow" in fopen.

There were no _s functions in VS6, but there was a strsafe.h library with names like
StringCchCopy, StringCchCat, StringCchPrintf, etc., and this library can also be included
in VS9. If you need compatibility of the other functions, I'd suggest using strsafe.h
functions which are backward compatible (if you have the latest VS6 Platform SDK,
something like October 2003 or something like that).

You can always do a #if, e.g.,

#if _MSC_VER > 1400
if(!fopen_s(..., &file))
#else
file = fopen(...);
if(file == NULL)
#endif

You can put this in a header file if you want, e.g.,

#if _MSC_VER > 1400
#define OPEN_FILE(fname, mode, result) fopen_s(fname, mode, &result)
#else
#define OPEN_FILE(fname, mode, result) result = fopen(fname, mode)
#endif
joe

On Tue, 10 Nov 2009 11:32:10 -0800 (PST), Uwe Kotyczka <uwe.kotyczka(a)web.de> wrote:

>Hi,
>
>I have been working with VC6.0 for a long time.
>Now I have access to Visual Studio 2008 (not at
>home), so I tried to compile an old VC6.0 project
>with the new IDE.
>
>It worked fine and did not require many changes
>in the code. However there were some warnings
>that I use depricated functions like fopen,
>sprintf, _tcsncpy an I better should use their
>save equivalents fopen_s, sprintf_s, _tcsncpy_s.
>
>No problem, the code compiles with those "_s"
>functions. Reading the MSDN documentation I find
>that fopen_s is availible from Win95 on.
>
>I would like to maintain the project for both
>VC6.0 and Visual Studio 2008. But in VC6.0 I cannot
>find any header/lib for fopen_s. Not in the
>headers which ship with VC6.0SP6 nor in the
>February 2003 SDK.
>
>Am I missing something or is it simply not
>possible to use functions like fopen_s in VC6.0?
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Scot Brennecke on 11 Nov 2009 03:41
Joseph M. Newcomer wrote:
> I find the fopen_s a truly weird mechanism, since there was nothing that could cause a
> "buffer overflow" in fopen.

Well, the "_s" is for "safe", not necessarily "safe from buffer
overflows". In the case of fopen_s, the sharing mode defaults to
_SH_SECURE instead of _SH_DENYNO. Also, the use of a FILE** parameter
instead of a FILE * return code might make it slightly harder for people
to do something stupid and dangerous with the return value.
From: Geoff on 11 Nov 2009 11:16
On Tue, 10 Nov 2009 11:32:10 -0800 (PST), Uwe Kotyczka
<uwe.kotyczka(a)web.de> wrote:

>No problem, the code compiles with those "_s"
>functions. Reading the MSDN documentation I find
>that fopen_s is availible from Win95 on.

Do not confuse compatibility with availability. The functions are
compatible if the mvscr80.dll is present and your application imports
from it. They are not available if the DLL is not present.
From: Joseph M. Newcomer on 11 Nov 2009 12:17
Interesting. I had not actually noticed that. But now there's a serious problem: suppose
I WANT to open the file with _SH_DENYNO. For example, if I want to open it in sharable
mode and I want to specify the encoding used. I note that _fsopen/_wfsopen/_tfsopen do
not appear to allow the ccs=encoding option. So instead of giving me complete control, I
only get a subset of the specifications in one (fopen_s) and a different, exlusive, subset
of specifications in another. But there appears to be no way to open a file in the C
library if I need to specify both sharing and encoding.

Unless, of course, _fsopen and _wfsopen allow me to specify the encoding, but neglected to
document it. I'm a bit busy today, and don't want to look it up, but I'm adding it as a
project to look into for my "errors and omissions" document.

[Side note: the MASM documentation in the MSDN has to be among the worst documentation I
have ever seen; it doesn't even give basic identifier syntax, uses some constructs whose
syntax is never even described ("initializer") and makes reference to pieces of syntax ("a
constant starting with %") that are never, ever explained anywhere else. I'm slowly
adding these to my list as I develop a course in assembly code programming]

Note that I hardly ever use the raw C library; I tend to use CStdioFile::Open to get file
objects for simple text I/O, which does allow me to set all the state I want.
joe
On Wed, 11 Nov 2009 02:41:55 -0600, Scot Brennecke <ScotB(a)spamhater.MVPs.org> wrote:

>Joseph M. Newcomer wrote:
>> I find the fopen_s a truly weird mechanism, since there was nothing that could cause a
>> "buffer overflow" in fopen.
>
>Well, the "_s" is for "safe", not necessarily "safe from buffer
>overflows". In the case of fopen_s, the sharing mode defaults to
>_SH_SECURE instead of _SH_DENYNO. Also, the use of a FILE** parameter
>instead of a FILE * return code might make it slightly harder for people
>to do something stupid and dangerous with the return value.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  | 
Pages: 1 2
Prev: Newbie question: Need for header file when linking to static library
Next: using CList as a base class in an extension DLL