From: Jorgen Grahn on
On 3 Jun 2006 07:53:46 -0400, kanze <kanze(a)gabi-soft.fr> wrote:
....
> 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!

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jorgen Grahn on
On 3 Jun 2006 20:41:03 -0400, James Kanze <kanze.james(a)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 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 ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: kanze on
Bo Persson wrote:
> "kanze" <kanze(a)gabi-soft.fr> skrev i meddelandet
> news:1149597722.585255.30990(a)i39g2000cwa.googlegroups.com...
> > Bo Persson wrote:
> >> <lists(a)givemefish.com> skrev i meddelandet
> >> news:1149149250.643455.166300(a)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


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Martin Bonner on

James Kanze wrote:
> Martin Bonner wrote:
> > lists(a)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.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: kanze on
Jorgen Grahn wrote:
> On 3 Jun 2006 20:41:03 -0400, James Kanze <kanze.james(a)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


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4
Prev: VC++ compiler bug?
Next: UTF8 and std::string