Secure CRT : question about freopen_s

[Aurelien Regat-Barrel]

Hi,
I am porting a VC++ 7.1 app to VC++ 8. I use freopen in order to connect
standard streams to a newly allocated console. The compiler tells me
that freopen is not safe:

AllocConsole();
std::freopen( "CONIN$", "r", stdin );
std::freopen( "CONOUT$", "w", stdout );
std::freopen( "CONOUT$", "w", stderr );
std::ios_base::sync_with_stdio();

Message: 'This function or variable may be unsafe. Consider using
freopen_s instead.

Hum, why not (but why ?).
So I try to use freopen_s, but I don't understand the mean of the 1st
parameter:

errno_t freopen(
FILE** pFile, // ...? *<|-@
const char *path,
const char *mode,
FILE *stream );

The MSDN doesn't help me much. What is pFile good for ?

After this call:

FILE *stream;
freopen_s( &stream, "CONIN$", "r", stdin );

What is the difference between stream and stdin ?

Thanks for your help.

[Doug Harrison [MVP]]

On Tue, 29 Nov 2005 16:11:05 +0100, Aurelien Regat-Barrel
<nospam....@yahoo.fr.invalid> wrote:

>Hi,
>I am porting a VC++ 7.1 app to VC++ 8. I use freopen in order to connect
>standard streams to a newly allocated console. The compiler tells me
>that freopen is not safe:
>
> AllocConsole();
> std::freopen( "CONIN$", "r", stdin );
> std::freopen( "CONOUT$", "w", stdout );
> std::freopen( "CONOUT$", "w", stderr );
> std::ios_base::sync_with_stdio();
>
>Message: 'This function or variable may be unsafe. Consider using
>freopen_s instead.
>
>Hum, why not (but why ?).

The freopen_s docs link to a page describing the Secure CRT changes. If it
doesn't satisfy, compare and contrast the source code.

>So I try to use freopen_s, but I don't understand the mean of the 1st
>parameter:
>

>errno_t freopen_s(

> FILE** pFile, // ...? *<|-@
> const char *path,
> const char *mode,
> FILE *stream );
>
>The MSDN doesn't help me much. What is pFile good for ?

It stores the return value of freopen.

>After this call:
>
> FILE *stream;
> freopen_s( &stream, "CONIN$", "r", stdin );
>
>What is the difference between stream and stdin ?

If the call succeeds, stream will equal stdin. If the call fails, stream
will be NULL.

--
Doug Harrison
Visual C++ MVP

[Aurelien Regat-Barrel]

>>So I try to use freopen_s, but I don't understand the mean of the 1st
>>parameter:
>>
>>errno_t freopen_s(
>> FILE** pFile, // ...? *<|-@
>> const char *path,
>> const char *mode,
>> FILE *stream );
>>
>>The MSDN doesn't help me much. What is pFile good for ?
>
>
> It stores the return value of freopen.
>
>
>>After this call:
>>
>> FILE *stream;
>> freopen_s( &stream, "CONIN$", "r", stdin );
>>
>>What is the difference between stream and stdin ?
>
>
> If the call succeeds, stream will equal stdin. If the call fails, stream
> will be NULL.

Yes, that's the behaviour I understood. But, since stdin (last
parameter) is updated, I don't understand the need of the 1st one (and
why I can't pass it NULL). We already have a FILE*, so why do we need an
other ?

I tried to re-use stdin:

freopen_s( &stdin, "CONIN$", "r", stdin );

but in my case, as stdin is not a l-value, it doesn't compile, and I am
forced to create a dummy variable stream :-(
I don't find it very elegant, that's why I wanted to understand.

Thanks.

[Ale Contenti [MSFT]]

You're right, we could have made the first parameter of freopen_s accept NULL, since the return value of the original freopen is not often used.

Instead, the return value of fopen cannot really be ignored.

I opened a bug about freopen_s and we will try to improve it in the next releases.

About the "why" of freopen_s, it's the default sharing mode: if you're opening a file for writing (or writing and reading) the default share mode will be _SH_SECURE (see http://msdn2.microsoft.com/en-us/library/febdfes5.aspx)

Basically, if a file is read-only, then it will be open with _SH_DENYWR (i.e. share read access). In all the other cases (file open for write or open for read/write) the file will be open with _SH_DENYRW (i.e. exclusive access).

Thanks!

Ale Contenti
VC++ Libraries

[Aurelien Regat-Barrel]

Ale Contenti [MSFT] wrote :

> You're right, we could have made the first parameter of freopen_s accept NULL, since the return value of the original freopen is not often used.
>
> Instead, the return value of fopen cannot really be ignored.
>
> I opened a bug about freopen_s and we will try to improve it in the next releases.
>
> About the "why" of freopen_s, it's the default sharing mode: if you're opening a file for writing (or writing and reading) the default share mode will be _SH_SECURE (see http://msdn2.microsoft.com/en-us/library/febdfes5.aspx)
>
> Basically, if a file is read-only, then it will be open with _SH_DENYWR (i.e. share read access). In all the other cases (file open for write or open for read/write) the file will be open with _SH_DENYRW (i.e. exclusive access).

Thanks for the links and the explanations.

--
Aurélien Regat-Barrel