strncpy_s and gcc ?

[tmartsum]

I have been doing some (re)search on the VS-warning
warning C4996: 'strncpy' was declared deprecated

It seems to be a MS-way to force strncpy to become deprecated, but it
is not ISO-deprecated.

However MS wants this to be replaced with strncpy_s
1) Is it c++,TR1 or just MS standard (TR proposal) ?

2) gcc 4.1.1 does not seem to have strncpy_s - is that correct
(Or do I miss an include or something)

 

[Salt_Peter]

I have been doing some (re)search on the VS-warning
warning C4996: 'strncpy' was declared deprecated

It seems to be a MS-way to force strncpy to become deprecated, but it
is not ISO-deprecated.

However MS wants this to be replaced with strncpy_s
1) Is it c++,TR1 or just MS standard (TR proposal) ?

2) gcc 4.1.1 does not seem to have strncpy_s - is that correct
(Or do I miss an include or something)

Frankly, no-one cares what MS thinks. Copying an object, like a string,
should be handled by a copy constructor, period. When you hear MS say
the word "string", that can mean a lot of different things.

#include <string>

int main()
{
std::string s("a short string");
std::string copy(s); // and that's how you copy a string - copy ctor
- simplicity defined
}

 

[tmartsum]

Salt_Peter skrev:

Frankly, no-one cares what MS thinks. Copying an object, like a string,
should be handled by a copy constructor, period. When you hear MS say
the word "string", that can mean a lot of different things.

#include <string>

int main()
{
std::string s("a short string");
std::string copy(s); // and that's how you copy a string - copy ctor
- simplicity defined
}

You are right - this is the way it should be, but unfortunately it does
not answer my question on status on strncpy_s.

The situation is that I have a lot of old code with old char*-strings.
Now when I compile VS says something and gcc says something else.

What is the truth about it ?
So the question remains ....
(But thanks for your input)

 

[Kai-Uwe Bux]

I have been doing some (re)search on the VS-warning
warning C4996: 'strncpy' was declared deprecated

It seems to be a MS-way to force strncpy to become deprecated, but it
is not ISO-deprecated.

However MS wants this to be replaced with strncpy_s
1) Is it c++,TR1 or just MS standard (TR proposal) ?

There is no strncpy_s in the current standard. I also didn't find it in the
TR1 draft.

2) gcc 4.1.1 does not seem to have strncpy_s - is that correct
(Or do I miss an include or something)

The gcc mailing lists would be a good place for this question.


Best

Kai-Uwe Bux

 

[Roland Pibinger]

I have been doing some (re)search on the VS-warning
warning C4996: 'strncpy' was declared deprecated

Those functions shall make the notoriously error-prone C string
functions a little safer.

It seems to be a MS-way to force strncpy to become deprecated, but it
is not ISO-deprecated.
However MS wants this to be replaced with strncpy_s
1) Is it c++,TR1 or just MS standard (TR proposal) ?

IIRC, there are ongoing activities to standardize those functions.

2) gcc 4.1.1 does not seem to have strncpy_s - is that correct
(Or do I miss an include or something)

Maybe you'll find a free implementation?

Best wishes,
Roland Pibinger

 

[Michiel.Salters]

I have been doing some (re)search on the VS-warning
warning C4996: 'strncpy' was declared deprecated

It seems to be a MS-way to force strncpy to become deprecated, but it
is not ISO-deprecated.

Right. It isn't deprecated by C or C++. But since this is clc++, I'll
ignore ISO C.

However MS wants this to be replaced with strncpy_s
1) Is it c++,TR1 or just MS standard (TR proposal) ?

I think it was (part of) a proposal at some time, for the C++0x
release. It's
not in TR1, though.

2) gcc 4.1.1 does not seem to have strncpy_s - is that correct

Correct, but really off-topic here. ISO C++ doesn't have strncpy_s.

The level of verbosity typically depends on the exact compiler
settings. ISO
allows any warning, as long as legal C++ code still works. This
particular
warning can be turned off just with a setting, too. This would be the
best
approach if you desire portable code.

HTH,
Michiel Salters

 

[tmartsum]

(e-mail address removed) skrev:

Right. It isn't deprecated by C or C++. But since this is clc++, I'll
ignore ISO C.


I think it was (part of) a proposal at some time, for the C++0x
release. It's
not in TR1, though.


Correct, but really off-topic here. ISO C++ doesn't have strncpy_s.

The level of verbosity typically depends on the exact compiler
settings. ISO
allows any warning, as long as legal C++ code still works. This
particular
warning can be turned off just with a setting, too. This would be the
best
approach if you desire portable code.

HTH,
Michiel Salters

ISO allows any warning, as long as legal C++ code still works.

OK - so MS is allowed to give any warning - I am however not happy with
warnings that suggest me to change my code into something that is not
(ISO) c++...

 

[Jim Langston]

(e-mail address removed) skrev:

ISO allows any warning, as long as legal C++ code still works.

OK - so MS is allowed to give any warning - I am however not happy with
warnings that suggest me to change my code into something that is not
(ISO) c++...

That's Microsoft for you. And it should be _strncpy_s since it's an
extension. Microsoft did that from some calls from VC6 to VC .net 2003,
but on this one I think they thought it would be in the new standard or
something.

 

[Bart]

Frankly, no-one cares what MS thinks.

Well, the chair of the ISO C++ commitee is from Microsoft, and there's
only like eleventy billion lines of code written for MS platforms.
Perhaps MS does have something to say after all.

Regards,
Bart.

 

[Greg]

Salt_Peter skrev:

You are right - this is the way it should be, but unfortunately it does
not answer my question on status on strncpy_s.

The routine strncpy_s() and the other, related "_s"-suffixed Standard C
library routines are an ISO - and not a Microsoft - set of extensions.
Specifically the "bounds-checking" interfaces are a draft TR extension
to the standard C library. They will no doubt will eventually make
their way into the C and C++ Standards.

Nor would I recommend waiting before adopting bounds-checking routines
to replace their unsafe C library equivalents. After all, blind
adherernce to "standards" is no excuse for writing insecure programs.

For futher reading:

Status of various C Standard projects:

http://www.open-std.org/JTC1/SC22/WG14/www/projects#24731

which includes a link to the latest Draft of the the bounds-checking C
Library extensions:

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1146.pdf

Greg

 

[Greg]

That's Microsoft for you. And it should be _strncpy_s since it's an
extension. Microsoft did that from some calls from VC6 to VC .net 2003,
but on this one I think they thought it would be in the new standard or
something.

Not necessarily. Whether strncpy_s is defined or not could be made
dependent on the definition of an implementation-reserved identifier.
Since no conforming program would have already defined this identifier,
there is no chance that the these extensions would break a conforming
program. Instead, a C or C++ program has to first define
__STDC_WANT_LIB_EXT1__ before it can call any of the routines in the TR
"bounds-checked" extension to the standard C library.

Greg

 

[Gavin Deane]

(e-mail address removed) skrev:

ISO allows any warning, as long as legal C++ code still works.

OK - so MS is allowed to give any warning - I am however not happy with
warnings that suggest me to change my code into something that is not
(ISO) c++...

Depending on your level of unhappiness, you have several options. For
example, you could do one or more of the following:

Contact Microsoft and give them your feedback as a customer.
Vote with your feet and change to a different compiler vendor.
Look in Microsoft's documentation for the way to switch off that
warning now you understand why it's there and why you don't want it.

The last one has worked for me.

Gavin Deane