April 2008 - Darwin-dev - lists.apple.com

Re: strptime cannot parse date older than 1938
by Nick Zitzmann 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Apr 25, 2008, at 1:10 AM, Surf Chen wrote: But I need to ask a final question:On Mac OSX and with 32 bit compile option, How to parse "Thu, 24-Apr-38 04:28:16 GMT" to struct tm or other structs like that? Do I need to down or write an alternative lib to parse it? Nick Zitzmann <http://www.chronosnet.com/> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… In addition to what everyone else has said, if you don't mind writing non-portable code, then you can do this with the Foundation framework using the NSDate, NSDateFormatter, and NSCalendar classes. You just can't do this using strptime(). This email sent to site_archiver(a)lists.apple.com

1 0

Re: strptime cannot parse date older than 1938
by Jamison Hope 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Apr 25, 2008, at 6:54 AM, Martin Costabel wrote: Thanks to the useful replies here. struct tm { int tm_sec; /* seconds after the minute [0-60] */ int tm_min; /* minutes after the hour [0-59] */ int tm_hour; /* hours since midnight [0-23] */ int tm_mday; /* day of the month [1-31] */ int tm_mon; /* months since January [0-11] */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday [0-6] */ int tm_yday; /* days since January 1 [0-365] */ int tm_isdst; /* Daylight Savings Time flag */ long tm_gmtoff; /* offset from CUT in seconds */ char *tm_zone; /* timezone abbreviation */ }; Remember back in 1999 when Apple was running ads talking about Y2K? I guess FAQ #1 here http://docs.info.apple.com/article.html?artnum=19843 isn't quite right anymore. -Jamie -- Jamison Hope The PTR Group www.theptrgroup.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Terry Lambert wrote: On Apr 25, 2008, at 12:10 AM, Surf Chen wrote: But I need to ask a final question:On Mac OSX and with 32 bit compile option, How to parse "Thu, 24-Apr-38 04:28:16 GMT" to struct tm or other structs like that? Do I need to down or write an alternative lib to parse it? You don't, it's out of range. What is out of range in struct tm? The only thing that can be out of range is the number of seconds from the Epoch, but this is not a member of struct tm: That's why it's called "The UNIX Y2038 bug". That's right, this is a bug. A bug in Apple's implementation of the strptime function. There is no mention of 2038 in the documentation of this function, and there is no reason why it should not work as advertised, even on a 32bit system. It's a bug that should be fixed. "We may not get everything right, but at least we knew the century was going to end. Macintosh was designed to work perfectly with dates all the way up to the year 29,940. But have no fear. We’re already hard at work on the Y30K problem." This email sent to site_archiver(a)lists.apple.com

1 0

Compiling CFLite
by Alex Cohen 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: Acim0qHrcHgJ4SIZyEeGX+lLSIZYRw== Thread-topic: Compiling CFLite User-agent: Microsoft-Entourage/11.2.5.060620 Hi, I'm about to try and compile the latest CFLite on windows vista with visual studio 2008. Has anyone done this in the past? Are there any projects available to help me out? Thx AC _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: strptime cannot parse date older than 1938
by Martin Costabel 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Thanks to the useful replies here. But I need to ask a final question:On Mac OSX and with 32 bit compile option, How to parse "Thu, 24-Apr-38 04:28:16 GMT" to struct tm or other structs like that? Do I need to down or write an alternative lib to parse it? struct tm { int tm_sec; /* seconds after the minute [0-60] */ int tm_min; /* minutes after the hour [0-59] */ int tm_hour; /* hours since midnight [0-23] */ int tm_mday; /* day of the month [1-31] */ int tm_mon; /* months since January [0-11] */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday [0-6] */ int tm_yday; /* days since January 1 [0-365] */ int tm_isdst; /* Daylight Savings Time flag */ long tm_gmtoff; /* offset from CUT in seconds */ char *tm_zone; /* timezone abbreviation */ }; -- Martin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Terry Lambert wrote: On Apr 25, 2008, at 12:10 AM, Surf Chen wrote: You don't, it's out of range. What is out of range in struct tm? The only thing that can be out of range is the number of seconds from the Epoch, but this is not a member of struct tm: That's why it's called "The UNIX Y2038 bug". That's right, this is a bug. A bug in Apple's implementation of the strptime function. There is no mention of 2038 in the documentation of this function, and there is no reason why it should not work as advertised, even on a 32bit system. It's a bug that should be fixed. This email sent to site_archiver(a)lists.apple.com

1 0

Re: strptime cannot parse date older than 1938
by Steve Checkoway 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Apr 25, 2008, at 2:46 AM, Surf Chen wrote: The code I posted above is work fine on 32 bit linux box(of cource with 32-bit c std lib). The time_t on my 32 bit linux box is 32 bits(sizeof(time_t)==4),but the y2038 bug not raised.So can I say the GNU version strptime DO NOT use time_t during the parsing? You should probably say "does not." But the code not works on my 32bit mac osx,so can I say the darwin implementation of strptime DO use time_t during the parsing? And again here, "strptime does use..." And If I want to make the code works correctly on my 32bit mac osx,I should write my own code to implement? Unfortunately, it seems like that is your only choice. Can you all use simple English when reply?I get puzzled when come with too complicate senctence.. Here I came with one:(I am so sorry for my bad English ability) Don't worry, your English is quite good. -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com Personally, I don't think it is reasonable to have such a restriction. We shouldn't be pretending that time after 2038 doesn't exist and struct tm shouldn't have those requirements at all. (In fact, it makes very little sense to have the year start at 1900. It could very easily start at 0 and have 2008 really mean 2008, stupid standards.) The int for the year is more than big enough to handle 2038 or 20380. Using time_t internally for strptime makes no sense at all (from an outsider's perspective). There is already something in place to handle failure of mktime() to convert from struct tm to time_t, namely returning -1. The limitations of struct tm shouldn't carry over to struct tm (and they clearly don't have to as running the code on Linux shows). I recommend you file a bug report <http://bugreport.apple.com>. smime.p7s

1 0

Re: strptime cannot parse date older than 1938
by Surf Chen 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SgaB6WMHYy642+bpJ62273ZfSUCRG06gOMXlJ0DAN+8=; b=o7nvqduHkDMyHUBFtfk2Un2n12ufm+8x6ojs0lBe5R1bz1fLUrukK9n9TyTKK227G7Z5xnVfDGJBwzrMbhrvVcyvGMvA6WjUSjpepZqMPnG5L6J9lSXTeCarEhmruOblrWDjZh0444vtkck50nn8lpjxt7P9m7dT0eQk8SL+NPg= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F+JKbD5tgsdp4PwslkmlN0EbTFs+WSJoTy1blZS6yHexuK685oJTMdeNupDSX4QRqUiAFUC5HP3XXRut1yKWXCtsRTVG3aXO8r/7VPs+aFvJ1k4N4YlAFXWEATKvMT9Fz3Wn0gUHZL+bh/g/adO9Nr/+X/Wemvq8gVVEFZvzMug= The code I posted above is work fine on 32 bit linux box(of cource with 32-bit c std lib). The time_t on my 32 bit linux box is 32 bits(sizeof(time_t)==4),but the y2038 bug not raised.So can I say the GNU version strptime DO NOT use time_t during the parsing? But the code not works on my 32bit mac osx,so can I say the darwin implementation of strptime DO use time_t during the parsing? And If I want to make the code works correctly on my 32bit mac osx,I should write my own code to implement? Can you all use simple English when reply?I get puzzled when come with too complicate senctence.. Here I came with one:(I am so sorry for my bad English ability) On Fri, Apr 25, 2008 at 4:34 PM, Terry Lambert <tlambert(a)apple.com> wrote: >.....but short of writing your own code to do the > parsing and storing the date as a string, you simply aren't going to be able > to do this portably. On Fri, Apr 25, 2008 at 4:34 PM, Terry Lambert <tlambert(a)apple.com> wrote: > On Apr 25, 2008, at 12:10 AM, Surf Chen wrote: > > > Thanks to the useful replies here. > > > > But I need to ask a final question:On Mac OSX and with 32 bit compile > > option, How to parse "Thu, 24-Apr-38 04:28:16 GMT" to struct tm or > > other structs like that? Do I need to down or write an alternative lib > > to parse it? > > > > You don't, it's out of range. > > That's why it's called "The UNIX Y2038 bug". Just like all those COBOL > programs that had "The Y2K bug" in the way they handled dates, e.g.: > > WORKING-STORAGE SECTION. > 01 DATE-FIELD. > 05 DAY PIC 99 VALUE ZEROS. > 05 MONTH PIC 99 VALUE ZEROS. > 05 YEAR PIC 99 VALUE ZEROS. > > ...years with values outside the range 00-99 were simply out of range and > impossible to represent in memory. That's why there was a lot of money > parsing COBOL code into a data dictionary, identifying this type of issue, > and emitting refactored COBOL source code without the bug. > > As we approach Y2038, I expect there will be a lot of UNIX jobs doing the > same thing for Epoch-based dates. See: > > <http://en.wikipedia.org/wiki/Year_2038_problem> > > I expect most code will be 64 bit by then, and then we'll be safe until we > hit "The Y290G bug". > > > > > > I don't want to mix different quetions here,just want to make sure > > that I should forsake strptime right now. > > > > I could go into gory details on what portable code can and cannot expect > from a UNIX compliant host OS, but short of writing your own code to do the > parsing and storing the date as a string, you simply aren't going to be able > to do this portably. > > -- Terry > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: strptime cannot parse date older than 1938
by Terry Lambert 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks to the useful replies here. But I need to ask a final question:On Mac OSX and with 32 bit compile option, How to parse "Thu, 24-Apr-38 04:28:16 GMT" to struct tm or other structs like that? Do I need to down or write an alternative lib to parse it? You don't, it's out of range. WORKING-STORAGE SECTION. 01 DATE-FIELD. 05 DAY PIC 99 VALUE ZEROS. 05 MONTH PIC 99 VALUE ZEROS. 05 YEAR PIC 99 VALUE ZEROS. <http://en.wikipedia.org/wiki/Year_2038_problem> I don't want to mix different quetions here,just want to make sure that I should forsake strptime right now. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Apr 25, 2008, at 12:10 AM, Surf Chen wrote: That's why it's called "The UNIX Y2038 bug". Just like all those COBOL programs that had "The Y2K bug" in the way they handled dates, e.g.: ...years with values outside the range 00-99 were simply out of range and impossible to represent in memory. That's why there was a lot of money parsing COBOL code into a data dictionary, identifying this type of issue, and emitting refactored COBOL source code without the bug. As we approach Y2038, I expect there will be a lot of UNIX jobs doing the same thing for Epoch-based dates. See: I expect most code will be 64 bit by then, and then we'll be safe until we hit "The Y290G bug". I could go into gory details on what portable code can and cannot expect from a UNIX compliant host OS, but short of writing your own code to do the parsing and storing the date as a string, you simply aren't going to be able to do this portably. This email sent to site_archiver(a)lists.apple.com

1 0

Re: strptime cannot parse date older than 1938
by Surf Chen 25 Apr '08

25 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0z+RcMyuZYt/3laGfFID2PIo0t9FGYJNLYjp3Rwk5wE=; b=gnZAdL43gD2rL3JyaHfcbzKvsAf0dng3s5QhTO8t4dCuEikyRpgO0llTmTs5OytNN64NwS5kchZ9OOaVfzDM297yTXlxpRnf1LyKo6X54Op9leNwRx0pduLQ1wQmnA2qGsq0H7lgXNG4/V8w4ZcewmnOj46lrOt5EcBvxgJ8wVA= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CEYInV/gBkpND4Nof/cwuRHDQvSQw3HEFTlZC0utqHdn6Ce7/bBHxguIF3He2NJrWS8NRO61CaRTJUYP0bPJ/MsVSSJGrDOy+0iPmgTIiXxIVPVRY+Fv6S0vfAeuR2QZJ5EUkY0VkLjP7pTeT2nTN12z4Kchmuawb1odJ42+o4w= Thanks to the useful replies here. But I need to ask a final question:On Mac OSX and with 32 bit compile option, How to parse "Thu, 24-Apr-38 04:28:16 GMT" to struct tm or other structs like that? Do I need to down or write an alternative lib to parse it? I don't want to mix different quetions here,just want to make sure that I should forsake strptime right now. On Fri, Apr 25, 2008 at 2:58 AM, Terry Lambert <tlambert(a)apple.com> wrote: > > On Apr 24, 2008, at 3:48 AM, Surf Chen wrote: > > > Martin Costabel wrote: > > > > > Well, on the Mac it only works if you compile for a 64bit architecture. > > > > > > > Does means that it internally uses the type time_t on mac osx? > > > > > > > You wrote "older than 1938" which is fine in English, but you did not > > > > > mean 1938, you meant 2038. If in your program you write 1938 instead > > of 38 and %Y instead of %y, everything is OK. If you write 2038 and > > %Y, you get the same problem as for 38 and %y. > > > > oh...I make a big written mistake. > > > > Luckily everybody here knows the real meaning. > > > > Whether the date is before or after the Epoch depnds on the value and the > range. > > For a 32 bit signed time_t, the range is from -2^31 to 2^31. > > > <http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html> > > The only "bugs" I've seen so far in this thread are: > > (1) the 64 bit version of the code should be interpreting a %y 2 digit 38 > the same way as the 32 bit code, which is minorly forgivable, given that the > UNIX certification process was done before all of the 64 bit support was > dealt with, and humans who care about this sort of thing should be using %Y > and 4 digit dates. > > (2) the use of %Y and a 4 digit date on a system with a 32 bit time_t > should arguably cause strptime() to return NULL, indicating a conversion > error. > > (3) the value for tm_year should arguably be "38" instead of "69" for the > sample code, unless we are clamping down on pre-Epoch dates (I say arguably, > since the code could be considered correct, either way). > > All that said, I think I agree with Sun Microsystems that you should be > using getdate() instead, since it has better conversion specification and > error reporting: > > > <http://www.opengroup.org/onlinepubs/009695399/functions/getdate.html> > > > Please file a problem report about strptime(). > > -- Terry > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Where is atomicqueue?
by Terry Lambert 24 Apr '08

24 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com <http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/Thr eadSafety/chapter_5_section_6.html> [0:505] > find /usr/include -name "OSAtomic.h" /usr/include/libkern/OSAtomic.h Ah maybe you are talking about that header not containing the definition for OSAtomic queue? >From the 10.5 man page... Short answer: (1) It's protected by #ifdef __ppc__, so it's PPC only -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Apr 24, 2008, at 10:34 AM, Army Research Lab wrote: On 4/24/08 11:40 AM, "Shawn Erickson" <shawnce(a)gmail.com> wrote: On Thu, Apr 24, 2008 at 8:30 AM, Shawn Erickson <shawnce(a)gmail.com> wrote: On Thu, Apr 24, 2008 at 4:35 AM, Army Research Lab <ckaran(a)arl.army.mil > wrote: I've been poking through the man pages, and discovered the docs for <libkern/OSAtomic.h>; I see the documentation for atomic and for spinlock, but 'man barrier' also lists atomicqueue. Unfortunately, although the man pages claim that I should find it, it isn't there. I also can't find anything like it in /usr/include. Does it exist? BTW, I'm looking at all of this on a OS X 10.4.11 machine... That is on a 10.4.11 system with Xcode 2.5. "Most of these functions first appeared in Mac OS 10.4 (Tiger). The "Orig" forms of the boolean operations, the "int", "long" and "ptr" forms of compare-and-swap, and lockless enqueue/dequeue first appeared in Mac OS 10.5 (Leopard)." The atomic queue does exist on 10.4 when in the kernel. OK, maybe that is the problem then; I did look in /usr/include/libkern/OSAtomic.h before I posted, but there is just a comment about the queue, not the queue itself. Do I have to download the Darwin sources to get access to it? Note that I'm just curious here, the only thing I need is spinlock, and if I'm clever, I won't even need that. (2) It's in a header <libkern/OSAtomic.h>, so you should only _expect_ to be able to use it in the kernel; the fact that there are some inline functions there notwithstanding (3) The atual implementaiton is as an external symbol in the Libkern and System6.0 exports for PPC only So to get at it you will need to be linked against the kernel (you will need to be either kernel code or a KEXT), you will need to be running PPC-only, and you will need to declare an explicit dependency for your KEXT on an exported symbol set or on the entire kernel. This email sent to site_archiver(a)lists.apple.com

1 0

Re: strptime cannot parse date older than 1938
by Terry Lambert 24 Apr '08

24 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Does means that it internally uses the type time_t on mac osx? mean 1938, you meant 2038. If in your program you write 1938 instead of 38 and %Y instead of %y, everything is OK. If you write 2038 and %Y, you get the same problem as for 38 and %y. oh...I make a big written mistake. For a 32 bit signed time_t, the range is from -2^31 to 2^31. <http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html> The only "bugs" I've seen so far in this thread are: <http://www.opengroup.org/onlinepubs/009695399/functions/getdate.html> Please file a problem report about strptime(). -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Apr 24, 2008, at 3:48 AM, Surf Chen wrote: Martin Costabel wrote: Well, on the Mac it only works if you compile for a 64bit architecture. You wrote "older than 1938" which is fine in English, but you did not Luckily everybody here knows the real meaning. Whether the date is before or after the Epoch depnds on the value and the range. (1) the 64 bit version of the code should be interpreting a %y 2 digit 38 the same way as the 32 bit code, which is minorly forgivable, given that the UNIX certification process was done before all of the 64 bit support was dealt with, and humans who care about this sort of thing should be using %Y and 4 digit dates. (2) the use of %Y and a 4 digit date on a system with a 32 bit time_t should arguably cause strptime() to return NULL, indicating a conversion error. (3) the value for tm_year should arguably be "38" instead of "69" for the sample code, unless we are clamping down on pre-Epoch dates (I say arguably, since the code could be considered correct, either way). All that said, I think I agree with Sun Microsystems that you should be using getdate() instead, since it has better conversion specification and error reporting: This email sent to site_archiver(a)lists.apple.com

1 0