Prev: VC++ compiler bug?
Next: UTF8 and std::string
From: Jorgen Grahn on 8 Jun 2006 06:36 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 8 Jun 2006 06:35 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 8 Jun 2006 19:11 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 8 Jun 2006 19:20 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 9 Jun 2006 19:40
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! ] |