On Jan 9, 2008 11:25 PM, Duncan Patton a Campbell <[EMAIL PROTECTED]> wrote:
> This may be a bug in FreeBSD, because it will work correctly if I pass a size 
> of length +2 to strftime
> in OpenBSD.
>
>
> On Wed, 9 Jan 2008 22:06:42 -0600
> Duncan Patton a Campbell <[EMAIL PROTECTED]> wrote:
>
> > There appears to be a bug in strftime such that the last digit is chopped 
> > off the seconds.
> >
> > I built a gprolog instance with a time function primitive (to get around 
> > 27bit ints in gprolog/386)
> > so:
> >
> > Bool c_adstm(char *timeS0, long secs, char **newtm)
> > {
> >
> > struct tm Tm;
> > char *sZnewtm;
> > size_t Xlen0 = 0;
> > time_t    tm;
> >         Tm.tm_isdst = -1;
> >         Xlen0 = strlen(timeS0);
> >         sZnewtm = *newtm = (char*)Malloc(Xlen0+1);
> >         if(strptime(timeS0,"%Y%m%d%H%M%S",&Tm)==NULL) return FALSE;
> >         tm = mktime(&Tm) ;
> > fprintf(stdout,"B: %ld\n",tm);
> >         tm = tm + secs;
> > fprintf(stdout,"C: %ld\n",tm);
> >         if(localtime_r(&tm,&Tm)==NULL) return FALSE;
> > //      if(strftime(sZnewtm,Xlen0,"%Y%m%d%H%M%S",&Tm)==0) return FALSE;
> >         strftime(sZnewtm,Xlen0,"%Y%m%d%H%M%S",&Tm) ;
> > fprintf(stdout,"E\n");
> >         return TRUE;
> > }
> >
> > When I run this on OpenBSD I get
> > | ?- c_adstm("20080101010101",30,X),atom_codes(XA,X).
> > B: 1199174461
> > C: 1199174491
> > E
> >
> > X = [50,48,48,56,48,49,48,49,48,49,48,49,51]
> > XA = '2008010101013'
> >
> > yes
> > | ?-
> >
> > But on FreeBSD I get the correct (expected) output:
> > | ?- c_adstm("20080101010101",30,X),atom_codes(XA,X).
> > B: 1199170861
> > C: 1199170891
> > E
> >
> > X = [50,48,48,56,48,49,48,49,48,49,48,49,51,49]
> > XA = '20080101010131'
> >
> > yes
> > | ?-
> >
> > I have entered a bug with sendbug/1, but it told me some (unspecified) 
> > fields
> > were blank so I'm not sure if it went in.
> >
> > Also, could anyone tell me where the source for the strftime & strptime 
> > functions is located?
> >
> > Thanks,
> > Dhu

man 3 strftime

The maxsize parameter is the buffer size _including_ terminating NUL,
so the bug is yours.

Also note the BUGS section which warns that other implementations may
not NUL-terminate the string if the length is not large enough.
Sounds like the standard wasn't specific enough.

--david

Reply via email to