strlen deprecated ?!?

[Matt Parkins]

Hi,

(I realise this probably isn't precisely the right group for this - could
someone direct me to the appropriate group to post this question? - thanks
!)

I'm using Visual C++ 2005 Express Edition Beta (free download from MS -
hooray!), and everything works fine, except I get warnings back on the use
of some functions, strlen() for example, saying that the function has been
deprecated - although they do still work (which is I guess why its a warning
and not an error!).

Does anyone have any idea which string functions (and other functions that
seem to have recently been deprecated) MS would like us to use when using
their compiler ?

Thanks in advance,

Matt

 

[shez]

Hi,

(I realise this probably isn't precisely the right group for this - could
someone direct me to the appropriate group to post this question? - thanks
!)

I'm using Visual C++ 2005 Express Edition Beta (free download from MS -
hooray!), and everything works fine, except I get warnings back on the use
of some functions, strlen() for example, saying that the function has been
deprecated - although they do still work (which is I guess why its a warning
and not an error!).

Does anyone have any idea which string functions (and other functions that
seem to have recently been deprecated) MS would like us to use when using
their compiler ?

Thanks in advance,

Matt

Use strnlen instead. Or better yet, std::string has a length() method.
-shez-

 

[davidrubin]

MS has a functions

Use strnlen instead. Or better yet, std::string has a length() method.
-shez-

How can you use 'strnlen' if you don't know the length of the string?
This is a great benefit of 'strlen'. Suppose you want to connect a
character buffer to a streambuf; how would you find the length? /david

 

[Gernot Frisch]

Hi,

(I realise this probably isn't precisely the right group for this -
could someone direct me to the appropriate group to post this
question? - thanks !)

I'm using Visual C++ 2005 Express Edition Beta (free download from
MS - hooray!), and everything works fine, except I get warnings back
on the use of some functions, strlen() for example, saying that the
function has been deprecated - although they do still work (which is
I guess why its a warning and not an error!).

Does anyone have any idea which string functions (and other
functions that seem to have recently been deprecated) MS would like
us to use when using their compiler ?

Thanks in advance,

Matt

I guess MS wants you to use:
_tcslen, _tcsstr, _tcscpy, _tcscat, _tcsanything...
-Gernot

 

[Pete Becker]

Does anyone have any idea which string functions (and other functions that
seem to have recently been deprecated) MS would like us to use when using
their compiler ?

You'll have to ask Microsoft. Neither the C standard nor the C++
standard deprecates the C string functions.

 

[Victor Bazarov]

(I realise this probably isn't precisely the right group for this - could
someone direct me to the appropriate group to post this question? - thanks
!)
microsoft.public.vc.language

I'm using Visual C++ 2005 Express Edition Beta (free download from MS -
hooray!), and everything works fine, except I get warnings back on the use
of some functions, strlen() for example, saying that the function has been
deprecated - although they do still work (which is I guess why its a warning
and not an error!).

I just went ahead and created a project that has the only source file
(named "test.cpp"):
-----------------
#include <stdio.h>
#include <string.h>

int main()
{
printf("%d\n", strlen("abc"));
return 0;
}
-----------------
(as you can see it uses 'strlen'), and here is the result of its building:
------ Build started: Project: test, Configuration: Release Win32 ------
Compiling...
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40607.16 for
80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc /MD /GR
/Fp".\Release/test.pch" /FAs /Fa".\Release/" /Fo".\Release/"
/Fd".\Release/" /W4 /c ".\test.cpp"
test.cpp
Linking...
Merging manifest files...
Build log was saved at "file://...\VC 2005 Projects\test\Release\BuildLog.htm"
test - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

So, let me ask you this: WTF are you talking about?

Does anyone have any idea which string functions (and other functions that
seem to have recently been deprecated) MS would like us to use when using
their compiler ?

Microsoft would have an idea, but I don't see any deprecation messages
when I compile. Are you sure you're not using some "managed" nonsense?

V

 

[Unforgiven]

I'm using Visual C++ 2005 Express Edition Beta (free download from MS -
hooray!), and everything works fine, except I get warnings back on the use
of some functions, strlen() for example, saying that the function has been
deprecated - although they do still work (which is I guess why its a
warning and not an error!).

Does anyone have any idea which string functions (and other functions that
seem to have recently been deprecated) MS would like us to use when using
their compiler ?

These functions have been deprecated (by MS, not the C standard) because
they can be the source of potential security problems. The problem with
strlen is that it will never terminate (until the program crashes by an
access violation) if no '\0' is found, which is the reason for the
deprecation. Microsoft's idea is indeed that you should use strnlen instead,
specifying some reasonable maximum size to make sure the function will stop
at some point. Or as somebody already mentioned, you could use std::string
instead.

 

[Julie]

These functions have been deprecated (by MS, not the C standard) because
they can be the source of potential security problems. The problem with
strlen is that it will never terminate (until the program crashes by an
access violation) if no '\0' is found, which is the reason for the
deprecation. Microsoft's idea is indeed that you should use strnlen
instead, specifying some reasonable maximum size to make sure the
function will stop at some point. Or as somebody already mentioned, you
could use std::string instead.

But std::string.length() is no better than strlen() since it is probably
implemented in terms of strlen() or a simple loop w/o excessive length
termination, right?

So, in terms of Microsoft's library, strnlen() w/ an expected maximum is
definitely the most 'secure' option.

 

[shez]

How can you use 'strnlen' if you don't know the length of the string?
This is a great benefit of 'strlen'. Suppose you want to connect a
character buffer to a streambuf; how would you find the length?

/david

strnlen takes the size of the *buffer* (which you must always know).
It returns the length of the (null-terminated) *string*

These are two different sizes.

Your streambuf must know the size of your buffer (take it into the
ctor).

-shez-

 

[shez]

But std::string.length() is no better than strlen() since it is probably
implemented in terms of strlen() or a simple loop w/o excessive length
termination, right?

Nope. I have no idea how length() is normally implemented, but it is
part of the C++ standard, so it is *always* (well, usually ;P) the best
option. And I doubt that any sane implementation will use 'strlen'.
-shez-

 

[Ioannis Vranos]

Hi,

(I realise this probably isn't precisely the right group for this - could
someone direct me to the appropriate group to post this question? - thanks
!)

I'm using Visual C++ 2005 Express Edition Beta (free download from MS -
hooray!), and everything works fine, except I get warnings back on the use
of some functions, strlen() for example, saying that the function has been
deprecated - although they do still work (which is I guess why its a warning
and not an error!).

Does anyone have any idea which string functions (and other functions that
seem to have recently been deprecated) MS would like us to use when using
their compiler ?

In the latest public Beta I do not get any deprecation errors, both in
native mode and managed mode:


#include <cstring>
#include <iostream>


int main()
{
using namespace std;

char *s= "Testing std::strlen()";

cout<<strlen(s)<<"\n";
}





C:\c>cl /EHsc temp.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.41013 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.41013
Copyright (C) Microsoft Corporation. All rights reserved.

/out:temp.exe
temp.obj

C:\c>cl /clr temp.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.41013
for Microsoft (R) .NET Framework version 2.00.41013.0
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.41013
Copyright (C) Microsoft Corporation. All rights reserved.

/out:temp.exe
temp.obj

C:\c>temp
21

C:\c>

 

[Ioannis Vranos]

But std::string.length() is no better than strlen() since it is probably
implemented in terms of strlen() or a simple loop w/o excessive length
termination, right?

Actually, probably it is usually implemented by using an internal counter.

So, in terms of Microsoft's library, strnlen() w/ an expected maximum is
definitely the most 'secure' option.

In any case, either the OP has an old Beta or something, or it is a
hoax. I do not get any deprecation messages from VC++ 2005 Express Beta
for strlen(), neither for the <cstring> header or the <string.h> header.

 

[Pete Becker]

strnlen takes the size of the *buffer* (which you must always know).
It returns the length of the (null-terminated) *string*

However, strnlen is not part of Standard C or Standard C++. It is being
discussed by both committees as part of a future Technical Report. A TR
is not normative: standard-conforming compilers are not required to
implement it.

 

[Pete Becker]

Nope. I have no idea how length() is normally implemented, but it is
part of the C++ standard, so it is *always* (well, usually ;P) the best
option. And I doubt that any sane implementation will use 'strlen'.

Why not? (Well, aside from the fact that it doesn't meet the complexity
requirements). But as far as "security", there's no danger in using
strlen internally because the internal data is carefully controlled.
There's no risk of buffer overruns.

 

[Jerry Coffin]

Julie wrote:

[ ... ]

But std::string.length() is no better than strlen() since it is probably
implemented in terms of strlen() or a simple loop w/o excessive length
termination, right?

Not really -- std::string::length often looks roughly like this:

namespace std {
template</* ... */>
class string {
typedef unsigned size_type;

size_type current_length;
// ...
public:

size_type length() const { return current_length; }
};

};

The interface of std::string is designed specifically to support a
model in which the buffer of characters isn't normally terminated: it
has data() to retrieve a pointer to its buffer, and c_str() to retrieve
a pointer to the data with a terminator. If memory serves, the rest of
the specification is written to allow c_str() to reallocate the buffer
if necessary.

 

[Karl Heinz Buchegger]

Why not? (Well, aside from the fact that it doesn't meet the complexity
requirements). But as far as "security", there's no danger in using
strlen internally because the internal data is carefully controlled.
There's no risk of buffer overruns.

Hmm. You probably know this better then I do, but
isn't std::string required to be able to deal with '\0'
characters too? I guess this would create problems with
using the str...() family.

 

[Julie]

In any case, either the OP has an old Beta or something, or it is a
hoax. I do not get any deprecation messages from VC++ 2005 Express Beta
for strlen(), neither for the <cstring> header or the <string.h> header.

I recall hearing/reading about a specific compiler switch to enable such
'safety' warnings, probably not on by default.

 

[Jerry Coffin]

Jerry Coffin wrote:

[ ... ]

Not really -- std::string::length often looks roughly like this:

namespace std {
template</* ... */>
class string {

Oops -- that should be basic_string, of course. string itself is just a
typedef of basic_string over char.

 

[Pete Becker]

Hmm. You probably know this better then I do, but
isn't std::string required to be able to deal with '\0'
characters too? I guess this would create problems with
using the str...() family.

Yes, but strnlen would have the same problem.

 

[davidrubin]

My point is that deprecating 'strlen' is not useful because sometimes
you need to find the length of a string, and you *don't* know the
buffer length.