On Fri, Mar 5, 2010 at 12:34 AM, Silesh C V <[email protected]> wrote:
> On 3/5/10, Garrett Cooper <[email protected]> wrote:
>> On Thu, Mar 4, 2010 at 10:54 PM, Silesh C V <[email protected]> wrote:
>>> On 3/5/10, Garrett Cooper <[email protected]> wrote:
>>>> On Thu, Mar 4, 2010 at 9:54 PM, Silesh C V <[email protected]> wrote:
>>>>> On 3/4/10, Rishikesh K Rajak <[email protected]> wrote:
>>>>>>>Rishi,
>>>>>>
>>>>>>>Can you test this patch on the machine on which the tests got stuck
>>>>>>>earlier?
>>>>>>
>>>>>> Yes i tested and found that, it is failing.
>>>>>
>>>>> It is supposed to fail :) . What we  wanted was a way to come out of
>>>>> the tests if the
>>>>> alarm fails to ring.
>>>>>
>>>>>
>>>>>>
>>>>>> [r...@x335a rtc]# ./rtc-test /dev/rtc
>>>>>> rtc01       0  TINFO  :  RTC READ TEST:
>>>>>> rtc01       1  TPASS  :  RTC READ TEST Passed
>>>>>> rtc01       0  TINFO  :  Current Date/time is  03/03/10 12:38:26 PM
>>>>>> rtc01       0  TINFO  :  RTC ALARM TEST :
>>>>>> rtc01       0  TINFO  :  Alarm time set to 12:38:31.
>>>>>> rtc01       0  TINFO  :  Waiting 5 seconds for the alarm...
>>>>>> rtc01       2  TFAIL  :  Timed out waiting for the alarm
>>>>>> rtc01       0  TINFO  :  RTC UPDATE INTERRUPTS TEST :
>>>>>> rtc01       0  TINFO  :  Waiting for  5 update interrupts...
>>>>>> rtc01       0  TINFO  :  Update interrupt 1
>>>>>> rtc01       0  TINFO  :  Update interrupt 2
>>>>>> rtc01       0  TINFO  :  Update interrupt 3
>>>>>> rtc01       0  TINFO  :  Update interrupt 4
>>>>>> rtc01       0  TINFO  :  Update interrupt 5
>>>>>> rtc01       3  TPASS  :  RTC UPDATE INTERRUPTS TEST Passed
>>>>>> rtc01       0  TINFO  :  RTC Tests Done!
>>>>>> [r...@x335a rtc]# ls -l /dev/rtc*
>>>>>> crw-r--r-- 1 root root 10, 135 Feb 20 13:51 /dev/rtc
>>>>>> [r...@x335a rtc]#
>>>>>>
>>>>>>
>>>>>>
>>>>>> In fact while compiling there is some warning also.
>>>>>> [r...@x335a rtc]# make
>>>>>> cc rtc-test.c -O2 -Wall -I ../../../../include/ -L ../../../../lib/
>>>>>> -lltp  -o rtc-test
>>>>>> rtc-test.c: In function ‘read_alarm_test’:
>>>>>> rtc-test.c:64: warning: dereferencing type-punned pointer will break
>>>>>> strict-aliasing rules
>>>>>
>>>>> I did not get this warning on gcc-4.3.0 . Anyways I think we can get rid
>>>>> of this
>>>>> warning by using -fno-strict-aliasing option at the cost of some
>>>>> optimizations.
>>>>> I will send you another patch.
>>>>>
>>>>
>>>> Or maybe just fix the code to not type-pun by converting everything to
>>>> struct tm on the fly?
>>>>
>>>> Let's look at the difference between the two structures:
>>>>
>>>> struct rtc_time {
>>>>         int tm_sec;
>>>>         int tm_min;
>>>>         int tm_hour;
>>>>         int tm_mday;
>>>>         int tm_mon;
>>>>         int tm_year;
>>>>         int tm_wday;
>>>>         int tm_yday;
>>>>         int tm_isdst;
>>>> };
>>>>
>>>> struct tm
>>>> {
>>>>   int tm_sec;                   /* Seconds.     [0-60] (1 leap second) */
>>>>   int tm_min;                   /* Minutes.     [0-59] */
>>>>   int tm_hour;                  /* Hours.       [0-23] */
>>>>   int tm_mday;                  /* Day.         [1-31] */
>>>>   int tm_mon;                   /* Month.       [0-11] */
>>>>   int tm_year;                  /* Year - 1900.  */
>>>>   int tm_wday;                  /* Day of week. [0-6] */
>>>>   int tm_yday;                  /* Days in year.[0-365] */
>>>>   int tm_isdst;                 /* DST.         [-1/0/1]*/
>>>>
>>>> #ifdef  __USE_BSD
>>>>   long int tm_gmtoff;           /* Seconds east of UTC.  */
>>>>   __const char *tm_zone;        /* Timezone abbreviation.  */
>>>> #else
>>>>   long int __tm_gmtoff;         /* Seconds east of UTC.  */
>>>>   __const char *__tm_zone;      /* Timezone abbreviation.  */
>>>> #endif
>>>> };
>>>>
>>>> Note the extra fields down below -- they increase the structure size
>>>> by a non-trivial amount (12 bytes on 32-bit, 16 bytes on 64-bit),
>>>> which means that if one of the following two cases are made in
>>>> strftime tomorrow:
>>>>
>>>> 1. They use one of the timezone fields and it isn't properly cleared
>>>> (not the case today, but it could be on some older versions of Linux).
>>>> 2. They make assumptions about the size of the memory allocated and
>>>> thus go out of bounds.
>>>>
>>>> BOOM! Segfault... could worse happen in this case after the ioctl is
>>>> written out to /dev/rtc ?
>>>
>>> OK. Can we drop strftime then ?
>>
>> Why couldn't you memset ( , 0, ) the value and set the individual
>> fields?
>
>
> Sorry . But I could not understand what you meant by setting the
> individual fields.

struct tm thetime;

memset(&thetime, 0, sizeof(thetime));
thetime.tm_sec = rtc_tm.tm_sec;
/* ... */

>  One of the awesome things about strftime is that it's
>> localization aware if you use the right format strings (I know -- a
>> functional nice to have, not necessarily a need to have).
>>
>> Unfortunately one of 'em is American friendly only :/ :
>>
>>        %D     Equivalent  to  %m/%d/%y.  (Yecch -- for Americans only.
>> Ameri-
>>               cans should note that in other countries %d/%m/%y is rather
>> com-
>>               mon.   This  means  that in international context this format
>> is
>>               ambiguous and should not be used.) (SU)
>>
>>>>>> Please solve these problems and please send me a revised patch.
>>
>> Thanks,
>> -Garrett
>>
> Thanks,
> Silesh
>
> --
> Silesh
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to