On Fri, Mar 5, 2010 at 4:21 PM, Garrett Cooper <[email protected]> wrote:
> 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;
> /* ... */
>
I think doing this just for formatting and printing the time is a slight
overhead.
The better approach would be to print the time by accessing
the individual fields so that we can avoid all the conversion and type
casting
from rtc_tm to tm . Although we will miss some of the great features of
sfrtime,
this will save the code from being unnecessarily complex.I will send another
patch
omitting sfrtime.
Thanks,
Silesh
>
> > 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
> >
>
--
Silesh
------------------------------------------------------------------------------
Download Intel® 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