localtime deprecated?
li...@givemefish.com
while compiling an existing project in the new MSVC 2005 compiler, I
received the warning that:
: warning C4996: 'localtime' was declared deprecated
C:\Program Files\Microsoft Visual Studio
8\VC\include\time.inl(114) : see declaration of 'localtime'
Message: 'This function or variable may be unsafe. Consider
using localtime_s instead. To disable deprecation, use
_CRT_SECURE_NO_DEPRECATE. See online help for details.'
I wasn't aware that localtime was declared deprecated. Is this true?
And, if so, is the suggestion of localtime_s standard compliant?
If not, what should I use? [This program has to be
platform-independent, ISO C++.]
Thanks for your help,
Matthew.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Victor Bazarov
> while compiling an existing project in the new MSVC 2005 compiler, I
> received the warning that:
>
>> warning C4996: 'localtime' was declared deprecated
> C:\Program Files\Microsoft Visual Studio
> 8\VC\include\time.inl(114) : see declaration of 'localtime'
> Message: 'This function or variable may be unsafe. Consider
> using localtime_s instead. To disable deprecation, use
> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>
>
> I wasn't aware that localtime was declared deprecated. Is this true?
No.
> And, if so, is the suggestion of localtime_s standard compliant?
No.
> If not, what should I use? [This program has to be
> platform-independent, ISO C++.]
Keep using 'localtime' until MS comes to its senses (unlikely) or
until MS removes it completely from its library implementation (also
unlikely). When/If the latter happens, split the code using an ifdef
directive.
Or simply disable this bogus warning.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Bo Persson
<li...@givemefish.com> skrev i meddelandet
news:1149149250.6...@y43g2000cwc.googlegroups.com...
> Hi all,
>
> while compiling an existing project in the new MSVC 2005 compiler, I
> received the warning that:
>
> : warning C4996: 'localtime' was declared deprecated
> C:\Program Files\Microsoft Visual Studio
> 8\VC\include\time.inl(114) : see declaration of 'localtime'
> Message: 'This function or variable may be unsafe. Consider
> using localtime_s instead. To disable deprecation, use
> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>
>
> I wasn't aware that localtime was declared deprecated. Is this
> true?
No. There is a proposal to the C standards committee though. Written
by Guess Who.
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1172.pdf
>
> And, if so, is the suggestion of localtime_s standard compliant?
Not yet, at least.
>
> If not, what should I use? [This program has to be
> platform-independent, ISO C++.]
Then define _CRT_SECURE_NO_DEPRECATE to disable the waring.
Bo Persson
red floyd
> Hi all,
>
> while compiling an existing project in the new MSVC 2005 compiler, I
> received the warning that:
>
> : warning C4996: 'localtime' was declared deprecated
> C:\Program Files\Microsoft Visual Studio
> 8\VC\include\time.inl(114) : see declaration of 'localtime'
> Message: 'This function or variable may be unsafe. Consider
> using localtime_s instead. To disable deprecation, use
> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>
>
> I wasn't aware that localtime was declared deprecated. Is this true?
Microsoft has taken it upon itself to deprecate items it considers
"unsafe". The ISO committee has not deprecated localtime(), as far as I
know. Either disable C4996 or define _CRT_SECURE_NO_DEPRECATE.
kanze
> while compiling an existing project in the new MSVC 2005
> compiler, I received the warning that:
> : warning C4996: 'localtime' was declared deprecated
> C:\Program Files\Microsoft Visual Studio
> 8\VC\include\time.inl(114) : see declaration of 'localtime'
> Message: 'This function or variable may be unsafe. Consider
> using localtime_s instead. To disable deprecation, use
> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
> I wasn't aware that localtime was declared deprecated. Is
> this true?
Not by the C++ committee, nor by the C committee (I think).
Maybe by Microsoft. In fact, the message is misleading; I think
Microsoft has admitted this, and plans to change it in the next
release.
On the other hand, there are cases where localetime might be
unsafe -- it cannot be used in multithreaded code, for example.
And this fact was recognized and addressed by the C committee.
Except for the word "deprecated" itself, the Microsoft warning
pretty much corresponds to what the C committee has said.
> And, if so, is the suggestion of localtime_s standard compliant?
Not in the strictest sense. It is defined in a TR to C -- sort
of an official extension. Practically speaking, I would expect
most C compilers to gradually move to support it, much as C++
compilers try to support TR1 (except that a lot of C compilers
aren't moving, period). If the C compiler supports it, you will
likely get it automatically in C++, even if C++ doesn't (yet)
recognize the C TR.
For the moment, however, most C compilers, much less most C++
compilers, do not support it. (The copy of it that I have
access to is dated Sept. 9, 2005, and it is only a draft. So
it is very, very new.)
> If not, what should I use? [This program has to be
> platform-independent, ISO C++.]
I'm not sure what the C++ committee's position is with regards
to this TR -- given how new it is, I doubt that the C++
committee has even considered it. Practically speaking, you
can't use anything in it in portable code. Yet.
I might add that I just love the fact that we now have three
"standard" functions to do exactly the same thing: localtime
(which, however, cannot be used in a multithreaded environment),
localtime_r (from Posix, to support multithreaded environments),
and localtime_s (the C committee's answer to the problem).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Martin Bonner
li...@givemefish.com wrote:
> Hi all,
>
> while compiling an existing project in the new MSVC 2005 compiler, I
> received the warning that:
>
> : warning C4996: 'localtime' was declared deprecated
> C:\Program Files\Microsoft Visual Studio
> 8\VC\include\time.inl(114) : see declaration of 'localtime'
> Message: 'This function or variable may be unsafe. Consider
> using localtime_s instead. To disable deprecation, use
> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>
>
> I wasn't aware that localtime was declared deprecated. Is this true?
you haven't asked is WHO declared it deprecated. The answer is
Microsoft (because if used carelessly, localtime can overflow a
buffer).
>
> And, if so, is the suggestion of localtime_s standard compliant?
> If not, what should I use? [This program has to be
> platform-independent, ISO C++.]
In that case, you should use localtime (and you probably want to
disable the warning). Of course if you are stuck in one of those
foolish shops that /also/ say "code must compile warning free with all
warnings enabled", you are a bit stuck!
Jake Montgomery
> li...@givemefish.com wrote:
>
>>while compiling an existing project in the new MSVC 2005
>>compiler, I received the warning that:
>
>
>>: warning C4996: 'localtime' was declared deprecated
>>
>>I wasn't aware that localtime was declared deprecated. Is
>>this true?
>
>
> Not by the C++ committee, nor by the C committee (I think).
> Maybe by Microsoft. In fact, the message is misleading; I think
> Microsoft has admitted this, and plans to change it in the next
> release.
>
> On the other hand, there are cases where localetime might be
> unsafe -- it cannot be used in multithreaded code, for example.
> And this fact was recognized and addressed by the C committee.
> Except for the word "deprecated" itself, the Microsoft warning
> pretty much corresponds to what the C committee has said.
>
Could you explain why localtime is considered to be inherently unsafe
for multithreading? It would seem that its thread safety would be
implementation dependent ... especially since AFAIK the C++ standard
does not address threading at all. It would seem that the tm structure
returned would be "per-thread" in any self respecting mutlithreaded
standard C++ library. Is that a naive assumption, or am I missing
something else in the definition that makes it inherently unsafe?
Curious,
Jake Montgomery
James Kanze
> li...@givemefish.com wrote:
>> while compiling an existing project in the new MSVC 2005
>> compiler, I received the warning that:
>> : warning C4996: 'localtime' was declared deprecated
>> C:\Program Files\Microsoft Visual Studio
>> 8\VC\include\time.inl(114) : see declaration of 'localtime'
>> Message: 'This function or variable may be unsafe. Consider
>> using localtime_s instead. To disable deprecation, use
>> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>> I wasn't aware that localtime was declared deprecated. Is
>> this true?
> Yes. You can see the declaration in the error message. The
> question you haven't asked is WHO declared it deprecated. The
> answer is Microsoft (because if used carelessly, localtime can
> overflow a buffer).
Can it? I don't think so. On the other hand, there is no way
to use it at all in a multithreaded environment. Which raises
an interesting question: if C++ adopts threading as part of the
language, do we also adopt this TR? Or?
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
[...]
> Could you explain why localtime is considered to be inherently
> unsafe for multithreading?
Read the specification. I suppose it could be made thread safe
by using some sort of thread local storage, but in general, the
wording of the standard encourages the use of static data.
> It would seem that its thread safety would be implementation
> dependent ... especially since AFAIK the C++ standard does not
> address threading at all.
The fact that the standard doesn't address threading at all
means that you have undefined behavior as soon as there is more
than one thread.
> It would seem that the tm structure returned would be
> "per-thread" in any self respecting mutlithreaded standard C++
> library.
Well, it's definitely not the case in Posix, which introduced
localtime_r to avoid the problem. It might be the case in some
Windows libraries, however; I'm not sure.
> Is that a naive assumption, or am I missing something else in
> the definition that makes it inherently unsafe?
I think it's a naive assumption, although I can see where it
makes sense. In practice, early threading systems, at least on
Unix systems, didn't have any direct support for thread local
storage, and emulating it was felt to be too expensive, and
possibly to introduce memory leaks -- you allocate the thread
local memory the first time the function is called within a
given thread, but when do you free it?
--
James Kanze kanze...@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Robert Kindred
"Victor Bazarov" <v.Aba...@comAcast.net> wrote in message
news:e5mogb$udv$1...@news.datemas.de...
> li...@givemefish.com wrote:
[]
>> And, if so, is the suggestion of localtime_s standard compliant?
>
> No.
>
>> If not, what should I use? [This program has to be
>> platform-independent, ISO C++.]
>
> Keep using 'localtime' until MS comes to its senses (unlikely) or
> until MS removes it completely from its library implementation (also
> unlikely). When/If the latter happens, split the code using an ifdef
> directive.
I am afraid "remove completely" is not so far fetched. I prefer to use
opendir and readdir to scan directories for a modicum of platform
independence. This worked in Borland Builder5, but it is gone from
Microsoft VS2005.
Robert Kindred
Victor Bazarov
> "Victor Bazarov" <v.Aba...@comAcast.net> wrote in message
> news:e5mogb$udv$1...@news.datemas.de...
>> li...@givemefish.com wrote:
> []
>>> And, if so, is the suggestion of localtime_s standard compliant?
>>
>> No.
>>
>>> If not, what should I use? [This program has to be
>>> platform-independent, ISO C++.]
>>
>> Keep using 'localtime' until MS comes to its senses (unlikely) or
>> until MS removes it completely from its library implementation (also
>> unlikely). When/If the latter happens, split the code using an ifdef
>> directive.
>
> I am afraid "remove completely" is not so far fetched. I prefer to
> use opendir and readdir to scan directories for a modicum of platform
> independence. This worked in Borland Builder5, but it is gone from
> Microsoft VS2005.
The biggest difference between 'localtime' and 'opendir' or 'readdir'
is that 'localtime' is a _Standard_C_Library_ function, the latter two
aren't.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
kanze
> <li...@givemefish.com> skrev i meddelandet
> news:1149149250.6...@y43g2000cwc.googlegroups.com...
> > while compiling an existing project in the new MSVC 2005
> > compiler, I received the warning that:
> > : warning C4996: 'localtime' was declared deprecated
> > C:\Program Files\Microsoft Visual Studio
> > 8\VC\include\time.inl(114) : see declaration of 'localtime'
> > Message: 'This function or variable may be unsafe. Consider
> > using localtime_s instead. To disable deprecation, use
> > _CRT_SECURE_NO_DEPRECATE. See online help for details.'
> > I wasn't aware that localtime was declared deprecated. Is
> > this true?
> No. There is a proposal to the C standards committee though. Written
> by Guess Who.
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1172.pdf
By who? A priori, by the ISO C committee, according to what I
can see. (As far as I know, Microsoft is not active in WG14.
Although I could be wrong, since I'm only indirectly active in
it myself. And don't forget that between the start of writing,
and the moment the document becomes official, it can easily take
five years.)
Note that there is a problem with localtime in a multithreaded
environment, and that Posix has also proposed a replacement,
required on Posix conformant platforms which support threading.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Francis Glassborow
<ka...@gabi-soft.fr> writes
>By who? A priori, by the ISO C committee, according to what I
>can see. (As far as I know, Microsoft is not active in WG14.
>Although I could be wrong, since I'm only indirectly active in
>it myself. And don't forget that between the start of writing,
>and the moment the document becomes official, it can easily take
>five years.)
You are mistaken. MS is active in WG14 and has even gone so far as to
employ a consultant C Standards specialist (Randy Meyers) to represent
them on the issue of the library TR (among other things that places a
desirable buffer between their C development teams and the proposals)
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Peter C. Chapin
@g10g2000cwb.googlegroups.com:
>> And, if so, is the suggestion of localtime_s standard compliant?
>
> Not in the strictest sense. It is defined in a TR to C -- sort
> of an official extension. Practically speaking, I would expect
> most C compilers to gradually move to support it, much as C++
> compilers try to support TR1 (except that a lot of C compilers
> aren't moving, period). If the C compiler supports it, you will
> likely get it automatically in C++, even if C++ doesn't (yet)
> recognize the C TR.
>
> For the moment, however, most C compilers, much less most C++
> compilers, do not support it. (The copy of it that I have
> access to is dated Sept. 9, 2005, and it is only a draft. So
> it is very, very new.)
Just an FYI... Open Watcom v1.5 supports TR24731 based on a document dated
2005-10-25. So there is at least one other compiler besides Microsoft's
that supports the *_s functions.
Peter
Bo Persson
"kanze" <ka...@gabi-soft.fr> skrev i meddelandet
news:1149597722....@i39g2000cwa.googlegroups.com...
> Bo Persson wrote:
>> <li...@givemefish.com> skrev i meddelandet
>> news:1149149250.6...@y43g2000cwc.googlegroups.com...
>
>> > while compiling an existing project in the new MSVC 2005
>> > compiler, I received the warning that:
>
>> > : warning C4996: 'localtime' was declared deprecated
>> > C:\Program Files\Microsoft Visual Studio
>> > 8\VC\include\time.inl(114) : see declaration of 'localtime'
>> > Message: 'This function or variable may be unsafe.
>> > Consider
>> > using localtime_s instead. To disable deprecation, use
>> > _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>
>> > I wasn't aware that localtime was declared deprecated. Is
>> > this true?
>
>> No. There is a proposal to the C standards committee though.
>> Written
>> by Guess Who.
>
>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1172.pdf
>
> By who?
By the compiler writer, sharing their experience on internal security
projects.
> A priori, by the ISO C committee, according to what I
> can see. (As far as I know, Microsoft is not active in WG14.
> Although I could be wrong, since I'm only indirectly active in
> it myself. And don't forget that between the start of writing,
> and the moment the document becomes official, it can easily take
> five years.)
It almost did.
I was thinking about the original proposal for the new function
signatures, originating from Microsoft (2003).
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n997.pdf
>
> Note that there is a problem with localtime in a multithreaded
> environment, and that Posix has also proposed a replacement,
> required on Posix conformant platforms which support threading.
Sure. My comment were general on deprecating functions in the C
library. Hasn't happened yet, but might happen.
MSVC 2005 marked these functions 'was declared deprecated' rather that
the intended 'is considered insecure', because it was less work doing
so. Someone thought that wasn't a big deal. :-)
Bo Persson
Jorgen Grahn
...
> I might add that I just love the fact that we now have three
> "standard" functions to do exactly the same thing: localtime
> (which, however, cannot be used in a multithreaded environment),
> localtime_r (from Posix, to support multithreaded environments),
> and localtime_s (the C committee's answer to the problem).
Does anyone know the reason for this, by the way? I read the original
posting, thought "good; I already have that function available here"
... and then noticed the different suffix (localtime_s versus localtime_r).
An unpleasant surprise.
I see people were complaining back in early 2005, when WDTR 24731 was voted
through:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1112.txt
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
Jorgen Grahn
> Martin Bonner wrote:
...
>> [...] The
>> question you haven't asked is WHO declared it deprecated. The
>> answer is Microsoft (because if used carelessly, localtime can
>> overflow a buffer).
>
> Can it? I don't think so.
Me neither.
> On the other hand, there is no way
> to use it at all in a multithreaded environment.
Am I missing something here? Surely it works if only a single thread needs
to call it, or if I add locking and copying around every call. And make very
sure I don't link against code which uses it.
I agree localtime() is broken, but at least it's not as broken as (for
example) gets(), which only works if you know noone will ever feed your
program bad input.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
kanze
> "kanze" <ka...@gabi-soft.fr> skrev i meddelandet
> news:1149597722....@i39g2000cwa.googlegroups.com...
> > Bo Persson wrote:
> >> <li...@givemefish.com> skrev i meddelandet
> >> news:1149149250.6...@y43g2000cwc.googlegroups.com...
> >> > while compiling an existing project in the new MSVC 2005
> >> > compiler, I received the warning that:
> >> > : warning C4996: 'localtime' was declared deprecated
> >> > C:\Program Files\Microsoft Visual Studio
> >> > 8\VC\include\time.inl(114) : see declaration of 'localtime'
> >> > Message: 'This function or variable may be unsafe.
> >> > Consider
> >> > using localtime_s instead. To disable deprecation, use
> >> > _CRT_SECURE_NO_DEPRECATE. See online help for details.'
> >> > I wasn't aware that localtime was declared deprecated. Is
> >> > this true?
> >> No. There is a proposal to the C standards committee though.
> >> Written
> >> by Guess Who.
> >> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1172.pdf
> > By who?
> By the compiler writer, sharing their experience on internal
> security projects.
Well, the final document was doubtlessly written by the project
editor, with some collaboration from other volonteers, and
approved by a vote in the general committee. You certainly
can't pin it on Microsoft alone.
> > A priori, by the ISO C committee, according to what I
> > can see. (As far as I know, Microsoft is not active in WG14.
> > Although I could be wrong, since I'm only indirectly active in
> > it myself. And don't forget that between the start of writing,
> > and the moment the document becomes official, it can easily take
> > five years.)
> It almost did.
> I was thinking about the original proposal for the new function
> signatures, originating from Microsoft (2003).
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n997.pdf
Interesting. I haven't been following the C committee too
closely. Given Microsoft's total lack of support for C99, I
just assumed that they were ignoring C (and the C committee)
completely.
> > Note that there is a problem with localtime in a multithreaded
> > environment, and that Posix has also proposed a replacement,
> > required on Posix conformant platforms which support threading.
> Sure. My comment were general on deprecating functions in the C
> library. Hasn't happened yet, but might happen.
> MSVC 2005 marked these functions 'was declared deprecated'
> rather that the intended 'is considered insecure', because it
> was less work doing so. Someone thought that wasn't a big
> deal. :-)
Or didn't understand the difference. (Don't think for a moment
that everyone at Microsoft is as competent as Herb sutter.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Martin Bonner
James Kanze wrote:
> Martin Bonner wrote:
> > li...@givemefish.com wrote:
>
> >> while compiling an existing project in the new MSVC 2005
> >> compiler, I received the warning that:
>
> >> : warning C4996: 'localtime' was declared deprecated
> >> C:\Program Files\Microsoft Visual Studio
> >> 8\VC\include\time.inl(114) : see declaration of 'localtime'
> >> Message: 'This function or variable may be unsafe. Consider
> >> using localtime_s instead. To disable deprecation, use
> >> _CRT_SECURE_NO_DEPRECATE. See online help for details.'
>
> >> I wasn't aware that localtime was declared deprecated. Is
> >> this true?
>
> > Yes. You can see the declaration in the error message. The
> > question you haven't asked is WHO declared it deprecated. The
> > answer is Microsoft (because if used carelessly, localtime can
> > overflow a buffer).
>
> Can it? I don't think so.
That will teach me to post without checking my facts. You are quite
right, it can't. It does have issues - just not buffer overflow
issues.
kanze
> On 3 Jun 2006 20:41:03 -0400, James Kanze <kanze...@neuf.fr> wrote:
> > Martin Bonner wrote:
> ...
> >> [...] The
> >> question you haven't asked is WHO declared it deprecated. The
> >> answer is Microsoft (because if used carelessly, localtime can
> >> overflow a buffer).
> > Can it? I don't think so.
> Me neither.
> > On the other hand, there is no way
> > to use it at all in a multithreaded environment.
> Am I missing something here? Surely it works if only a single thread
> needs to call it, or if I add locking and copying around every call.
> And make very sure I don't link against code which uses it.
I'm afraid I grossly overstated my case. It's definitely usable (at
least I think so) if you protect each call with a lock, copying the
results before freeing the lock. And as someone else suggested, an
implementation could even return a pointer to thread specific memory,
eliminating the need for the lock. The first is a lot of extra work
for
the user, however, and the second can result in extremely bad
performance, or maybe even memory leaks, under some systems.
> I agree localtime() is broken, but at least it's not as broken as (for
> example) gets(), which only works if you know noone will ever feed
> your program bad input.
Agreed. There are definitly different degrees of broken; gets() is
at about the highest degree, where as localtime() is considerably lower
(but still needs fixing).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34