Interesting warnings from latest MS compiler

[Noah Roberts]

The latest MS compiler "depricates" certain functions including
stricmp. The function stricmp is not part of the C++ standard, it is
part of POSIX. The question I have, is it really necissary for MS to
move from that name to _stricmp in order to be compliant with the C++
standard?

 

[Phlip]

The latest MS compiler "depricates" certain functions including
stricmp. The function stricmp is not part of the C++ standard, it is
part of POSIX. The question I have, is it really necissary for MS to
move from that name to _stricmp in order to be compliant with the C++
standard?

That's not legal deprecation. It's because MS programmers are not known for
their ability to refrain from permitting unchecked buffer overruns. So MS
now marks all the unchecked buffer functions as deprecated.

As an example of the problem, I have a lite web server on my home computer.
Every once in a while, something hits it with an URL containing a couple
hundred pad characters, 00000000000 or something, and then a little bit of
code.

Malware, somewhere, is probing for a known bug in a known server. (Not _my_
server, thank you!) So the main cause of all these security issues is
unchecked buffer handling in low-level code. So use fgets() instead of
gets(), and use snprintf() instead of sprintf().

And, heck, use std::string for gosh's sakes!!!

 

[red floyd]

The latest MS compiler "depricates" certain functions including
stricmp. The function stricmp is not part of the C++ standard, it is
part of POSIX. The question I have, is it really necissary for MS to
move from that name to _stricmp in order to be compliant with the C++
standard?

aren't all identifiers starting with "str" reserved by C89 (and
therefore C++)?

 

[Markus Schoder]

The latest MS compiler "depricates" certain functions including
stricmp. The function stricmp is not part of the C++ standard, it is
part of POSIX. The question I have, is it really necissary for MS to
move from that name to _stricmp in order to be compliant with the C++
standard?

stricmp is not POSIX. POSIX has strcasecmp though.

 

[Phlip]

...is it really necissary for MS to
move from that name to _stricmp in order to be compliant with the C++
standard?

That's not why they did it.

I thought the Standard(s) reserved all str.* functions for the
implementation, the same way as _[A-Z] are all reserved. So some str are
Standard Library, and some are whatever the implementation sez they are.

 

[Default User]

The latest MS compiler "depricates" certain functions including
stricmp. The function stricmp is not part of the C++ standard, it is
part of POSIX. The question I have, is it really necissary for MS to
move from that name to _stricmp in order to be compliant with the C++
standard?

The str* functions are reserved in the C standard for future library
directions. I don't know if that transfers to C++ that way.



Brian

 

[Default User]

The str* functions are reserved in the C standard for future library
directions. I don't know if that transfers to C++ that way.

Err, checking the standard, what I said is true for values of * == "a
lower case letter".



Brian

 

[Noah Roberts]

Phlip wrote:
]

And, heck, use std::string for gosh's sakes!!!]

Interestingly, several of the operations in the standard library,
including some in basic_string, are "depricated"


Potentially unsafe method
Safer equivalent

basic_string::copy
basic_string::_Copy_s

basic_istream::read
basic_istream::_Read_s

basic_istream::readsome
basic_istream::_Readsome_s

basic_streambuf::sgetn
basic_streambuf::_Sgetn_s

basic_streambuf::xsgetn
basic_streambuf::_Xsgetn_s

char_traits::copy
char_traits::_Copy_s

char_traits::move
char_traits::_Move_s

ctype::narrow
ctype::_Narrow_s

ctype::do_narrow
ctype::_Do_narrow_s

ctype::widen
ctype::_Widen_s

ctype::do_widen
ctype::_Do_widen_s

 

[Noah Roberts]

And, heck, use std::string for gosh's sakes!!!

It should be mentioned that there is no stricmp equiv in std::string.
You can create a string that does do that with basic_string and an
overridden char_traits, but this introduces other difficulties.

 

[Victor Bazarov]

It should be mentioned that there is no stricmp equiv in std::string.

It should probably also be mentioned that there is no stricmp in the C
Standard library either. Had there been one, std::string *would* have
its equivalent, most likely.

V

 

[Markus Schoder]

It should probably also be mentioned that there is no stricmp in the C
Standard library either. Had there been one, std::string *would* have
its equivalent, most likely.

There is a islower, isupper, tolower and toupper function in the C and
C++ standard libraries which means they are case aware. There is no
good reason why case insensitive comparison is not available or why C++
could not have fixed it in basic_string. It is just silly IMHO.

 

[Victor Bazarov]

There is a islower, isupper, tolower and toupper function in the C and
C++ standard libraries which means they are case aware. There is no
good reason why case insensitive comparison is not available or why
C++ could not have fixed it in basic_string. It is just silly IMHO.

I do not think so. There has to be some balance between what's provided
in the standard library and what's left to the programmer to implement.
Theoretically, you don't pay for what you don't use. Practically, though,
you always pay for the size of the library and the compiler and/or the
run-time environment. Why, FCOL, didn't C implement stricmp if there are
already all pieces there? Catch my drift?...

V

 

[Noah Roberts]

Theoretically, you don't pay for what you don't use. Practically, though,
you always pay for the size of the library and the compiler and/or the
run-time environment. Why, FCOL, didn't C implement stricmp if there are
already all pieces there? Catch my drift?...

Well, in this case (basic_string) the function is actually not
implemented if not used. As I understand it, member functions of
templates are not compiled unless called.

 

[Victor Bazarov]

Well, in this case (basic_string) the function is actually not
implemented if not used. As I understand it, member functions of
templates are not compiled unless called.

I guessed so much... You don't catch my drift. Oh well..

 

[Markus Schoder]

I do not think so. There has to be some balance between what's provided
in the standard library and what's left to the programmer to implement.
Theoretically, you don't pay for what you don't use. Practically, though,
you always pay for the size of the library and the compiler and/or the
run-time environment. Why, FCOL, didn't C implement stricmp if there are
already all pieces there? Catch my drift?...

Sure. But the reason is actually a different one as I just found out.
The case sensitivity stuff is considered to be locale dependent i.e.
the C function to use would be strcoll with the LC_COLLATE locale
category set to the appropriate value (this is also honored by tolower
et al).

C++ supports this as well through the localization library. There is
e.g. an operator() in the std::locale class that compares basic_string
objects.

 

[Markus Schoder]

Sure. But the reason is actually a different one as I just found out.
The case sensitivity stuff is considered to be locale dependent i.e.
the C function to use would be strcoll with the LC_COLLATE locale
category set to the appropriate value (this is also honored by tolower
et al).

C++ supports this as well through the localization library. There is
e.g. an operator() in the std::locale class that compares basic_string
objects.

Did a few tests and it turns out that strcoll at least for the locales
that I have available does not compare e.g. "a" and "A" as equal they
are just besides each other in the collation order.

So for true case insensitive comparisons you still have to roll your
own.

 

[Richard Herring]

There is a islower, isupper, tolower and toupper function in the C and
C++ standard libraries which means they are case aware. There is no
good reason why case insensitive comparison is not available or why C++
could not have fixed it in basic_string. It is just silly IMHO.

char what = toupper('ß');

 

[Noah Roberts]

I guessed so much... You don't catch my drift. Oh well..

Oh, are you drifting again?

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

There is a islower, isupper, tolower and toupper function in the C and
C++ standard libraries which means they are case aware. There is no
good reason why case insensitive comparison is not available or why C++
could not have fixed it in basic_string. It is just silly IMHO.

But the C functions only work on ASCII characters don't they? Or is the
character spec undefined? (probably undefined given that C will work
with EBCDIC or whatever it's called) You can't (generally) do case
conversion unless you know the language of the string in question
because the case rules vary from one language to another.

So, you can write some software that does the case conversion for ASCII
characters, but you don't really need a library to work out a-z == A-Z.

The most famous example of this is probably the "Turkish i". Turkish
Windows systems won't boot if you use the proper case conversion rules
for Turkish so they hobbled it (much to the annoyance of Turkish
speaking people, but much the favour of anybody from outside Turkey
trying to sell them software).

I gues Unix systems get around this by insisting that everything has
the right case (a file called 'A.txt' isn't the same as 'a.txt') and
this is what I've now done on my company's framework too.

 

[Phlip]

There is a islower, isupper, tolower and toupper function in the C and C++
standard libraries which means they are case aware. There is no good
reason why case insensitive comparison is not available or why C++ could
not have fixed it in basic_string. It is just silly IMHO.

The Standards are (sometimes) careful to leave things out that must then
get changed. islower etc are _not_ case-aware. They only do specific
case-like things to raw ASCII letters, so the Standards must leave them in
as the rock-bottom must-have functions.

So when C achieves a useful locale system, it may then support a
high-level strcompare() routine that rates encoded strings for equivalence.

Like Joel Spolsky sez somewhere, "There's no such thing as raw text!"