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&#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