"Krzysztof =AFelechowski" wrote:
> As you perhaps already know, Microsoft Visual C++ has taken the
> liberty of deprecating standard functions and methods on security
> grounds.  I do not want to discuss whether it is right or wrong;
> however, I do have a following problem:
>
> I want to provide mybuf::xsgetn.  However, xsgetn(char_type[],
> streamsize) is deprecated to _Xsgetn_s(char_type[], size_t,
> streamsize).  It would not be a problem if Microsoft did not allow me
> to call xsgetn since I agree it bears the risk a buffer overflow; but
> it gives a warning when I implement it as a private method!

Whas is the *problem* here?  A warning?  Take it up with Microsoft of
simply disable it in your program.  Or use a different compiler.

> I have the following choices now:
>
> 1. Do not implement xsgetn at all, which is a performance hit;
>
> 2. Implement _Xsgetn_s, which I can surely do, but I am not sure I am
> allowed to beause the identifier _Xsgetn_s is reserved.
>
> What do you think?

I don't think anything.  I couldn't care less.  I have always used and
will continue using standard functions whether or not MS decides to
warn me about their potential danger.  I keep driving a car although it
is known to sometimes cause injuries if driven into a wall at more than
5 mph without wearing or working restraints, and so do millions of other
folks.  Nobody tries to deprecate cars [yet].

MS is trying to look better and cover its ass because the world notices
all the vulnerabilities in their products.  They ought to educate their
own developers better, not try to prohibit the use of the "dangerous"
elements from the Standard Library.  Could it be that the warnings were
intended for the internal use and somehow leaked out?  I would not be
surprised.

V
--=20
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask=20


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

""Victor Bazarov"" <v.Abazarov@comAcast.net> skrev i meddelandet
news:e9nths$ac$1@news.datemas.de...

> Could it be that the warnings were
> intended for the internal use and somehow leaked out?  I would not
> be surprised.


It *was* intended for their internal use, and was found to be so good
that they couldn't even imagine anyone not wanting it on by default.

Luckily, there is a setting to revert to Standard C++. The OP should
just check the manual for the correct config macro.


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Bo Persson" <bop@gmb.dk> wrote:
>
> ""Victor Bazarov"" <v.Abazarov@comAcast.net> skrev i meddelandet
> news:e9nths$ac$1@news.datemas.de...
>
>> Could it be that the warnings were
>> intended for the internal use and somehow leaked out?  I would not
>> be surprised.
>
>
> It *was* intended for their internal use, and was found to be so good
> that they couldn't even imagine anyone not wanting it on by default.
>
> Luckily, there is a setting to revert to Standard C++. The OP should
> just check the manual for the correct config macro.
>
>
> Bo Persson
>

If I sought such an advice, I would have posted the question to
comp.lang.c++.moderated or, even more appropriate, paid $$$$ for
Microsoft Technical Support.  (Although I must admit I find these
warnings useful myself).

Please make a comment about virtual overridable member functions with
reserved names.  Is it all right to override them in user code?  I
provided the context in order to make things clearer, not to divert your
attention to Microsoft, let its name sink into perpetual oblivion.

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Christopher Conrade Zseleghovski" <kkz@duch.mimuw.edu.pl> skrev i
meddelandet news:e9u3v7$ri6$1@achot.icm.edu.pl...
> "Bo Persson" <bop@gmb.dk> wrote:
>>
>> ""Victor Bazarov"" <v.Abazarov@comAcast.net> skrev i meddelandet
>> news:e9nths$ac$1@news.datemas.de...
>>
>>> Could it be that the warnings were
>>> intended for the internal use and somehow leaked out?  I would not
>>> be surprised.
>>
>>
>> It *was* intended for their internal use, and was found to be so
>> good
>> that they couldn't even imagine anyone not wanting it on by
>> default.
>>
>> Luckily, there is a setting to revert to Standard C++. The OP
>> should
>> just check the manual for the correct config macro.
>>
>>
>> Bo Persson
>>
>
> If I sought such an advice, I would have posted the question to
> comp.lang.c++.moderated or, even more appropriate, paid $$$$ for
> Microsoft Technical Support.  (Although I must admit I find these
> warnings useful myself).

My comments were directed to Victor, who hadn't seen MS' apologies in
other fora. They just hadn't considered the possiblity that people may
want to write strictly compliant code, and not have the warnings
enabled by default.

>
> Please make a comment about virtual overridable member functions
> with
> reserved names.  Is it all right to override them in user code?

I wouldn't know. The standard just reserves some names for the
implementation, it doesn't say how thses names are going to be used.

So your options seems to be to either use the interface defined by the
standard (and deal with the warnings), or use the implementation
specific interface and rely on the implementation's documentation.
Virtual functions are obviously designed to be overridden, so that
cannot be a problem in itself.


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

As you perhaps already know, Microsoft Visual C++ has taken the liberty of
deprecating standard functions and methods on security grounds.  I do not
want to discuss whether it is right or wrong; however, I do have a following
problem:

I want to provide mybuf::xsgetn.  However, xsgetn(char_type[], streamsize)
is deprecated to _Xsgetn_s(char_type[], size_t, streamsize).  It would not
be a problem if Microsoft did not allow me to call xsgetn since I agree it
bears the risk a buffer overflow; but it gives a warning when I implement it
as a private method!
I have the following choices now:

1. Do not implement xsgetn at all, which is a performance hit;

2. Implement _Xsgetn_s, which I can surely do, but I am not sure I am
allowed to beause the identifier _Xsgetn_s is reserved.

What do you think?
Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Krzysztof    elechowski" wrote:
> I want to provide mybuf::xsgetn.  However, xsgetn(char_type[], streamsize)
> is deprecated to _Xsgetn_s(char_type[], size_t, streamsize).  It would not
> be a problem if Microsoft did not allow me to call xsgetn since I agree it
> bears the risk a buffer overflow; but it gives a warning when I implement it
> as a private method!
> I have the following choices now:
>
> 1. Do not implement xsgetn at all, which is a performance hit;
>
> 2. Implement _Xsgetn_s, which I can surely do, but I am not sure I am
> allowed to beause the identifier _Xsgetn_s is reserved.

I don't get it? What is wrong with option

3. Turn off these warnings, and implement xsgetn.

As far as I'm concerned, these warnings do not affect standard
compliance
(legal code compiles and works either way), but the only
standard-compliant
way to avoid them is to turn them off. Compiler settings are outside
the scope
of the standard.

BTW, do you get the warning when your xsgetn call another streambuf's
xsgetn?
Or did I misunderstand your problem?

Michiel.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

<Michiel.Salters@tomtom.com> wrote in message=20
news:1153401249.881102.79450@75g2000cwc.googlegroups.com...
> "Krzysztof =AFelechowski" wrote:
>> I want to provide mybuf::xsgetn.  However, xsgetn(char_type[],=20
>> streamsize)
>> is deprecated to _Xsgetn_s(char_type[], size_t, streamsize).  It would=
=20
>> not
>> be a problem if Microsoft did not allow me to call xsgetn since I agre=
e=20
>> it
>> bears the risk a buffer overflow; but it gives a warning when I implem=
ent=20
>> it
>> as a private method!
>> I have the following choices now:
>>
>> 1. Do not implement xsgetn at all, which is a performance hit;
>>
>> 2. Implement _Xsgetn_s, which I can surely do, but I am not sure I am
>> allowed to beause the identifier _Xsgetn_s is reserved.
>
> I don't get it? What is wrong with option
>
> 3. Turn off these warnings, and implement xsgetn.

If I turn them off, I may overlook a potential problem.  I find this warn=
ing=20
useful in general.

> As far as I'm concerned, these warnings do not affect standard
> compliance
> (legal code compiles and works either way), but the only
> standard-compliant
> way to avoid them is to turn them off. Compiler settings are outside
> the scope
> of the standard.
>
> BTW, do you get the warning when your xsgetn call another streambuf's
> xsgetn?
> Or did I misunderstand your problem?
>

I get the warning when I declare the method xsgetn.  It is that hard.

Chris=20


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]