Several programs have a hardcoded 19 in responses for the year. This will break in 4 years... This was fixed in NetBSD as PR misc/2308. (I think that I have the same changes as were finally committed) Fix: As I stated in the NetBSD PR: "There is also similiar code in "gnu/usr.bin/rcs/lib/rcstime.c", but I'm less sure of the proper fix there." parts = localtime(&time); ! sprintf (buf, "%d:%02d:%02d %s %d, 19%d", parts->tm_hour, parts->tm_min, parts->tm_sec, ! months[parts->tm_mon], parts->tm_mday, parts->tm_year); return(buf); } --- 467,475 ---- parts = localtime(&time); ! sprintf (buf, "%d:%02d:%02d %s %d, %d", parts->tm_hour, parts->tm_min, parts->tm_sec, ! months[parts->tm_mon], parts->tm_mday, 1900+parts->tm_year); return(buf); } How-To-Repeat: find /usr/src -type f -print | xargs grep '19%'
Stephen J. Roznowski wrote: > >Description: > > Several programs have a hardcoded 19 in responses for the year. > This will break in 4 years... > [...] > --- 1467,1474 ---- > struct tm *gmtime(); > t = gmtime(&stbuf.st_mtime); > reply(213, > ! "%04d%02d%02d%02d%02d%02d", > ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, Isn't there a TM_YEAR_BASE symbol defined somewhere that should be used instead of a hardcoded 1900? -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn"
> From: Mike Pritchard <mpp@freefall.freebsd.org> > Subject: Re: misc/1380: Year 2000 breakage with tm_year > > Stephen J. Roznowski wrote: > > >Description: > > > > Several programs have a hardcoded 19 in responses for the year. > > This will break in 4 years... > > [...] > > --- 1467,1474 ---- > > struct tm *gmtime(); > > t = gmtime(&stbuf.st_mtime); > > reply(213, > > ! "%04d%02d%02d%02d%02d%02d", > > ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, > > Isn't there a TM_YEAR_BASE symbol defined somewhere that should > be used instead of a hardcoded 1900? When I submitted my original changes to NetBSD, I used that symbol; however, according to "J.T. Conklin <jtc@NetBSD.ORG>" the definition of the tm_year field is "years since 1900" according to Standard C. [and not years since TM_YEAR_BASE] -SR
State Changed From-To: open->closed I've just done a new YTK survey using the find hack. We should now be YTK clean in all code/hardware support that we control. The following files are still "questionable" but interact with stuff outside our control: contrib/cvs/contrib/sccs2rcs.csh (sccs file format) usr.sbin/xntpd/parse/clk_trimtsip.c (hardware clock) I did not make patches to fix the old isdn software on the yacc tests, since that code is soon to die or times are irrelevant.