Re: Y2K bugs in OpenLDAP (ITS#233)

[warren.usui@platinum.com]

>	
>	True, but the YEAR_CAREFUL macro is:
>	
>	#define YEAR_CAREFUL(y)         ((y) < 1900 ? (y) + 1900 : (y))
>	
>	...
>	
>	#define YEAR(y) YEAR_CAREFUL(y)
>	
>	The check for (y) < 1900 is mostly harmless, I suppose, but it could
>	be dangerously confusing.  If tm_year >= 1900, you can safely assume
>	one of two things: either the C runtime is badly broken, or the current
>	year is 3800 or later.
>	
>	My suggestion: just assume that tm_year really is year-1900.  If you
>	really want to be paranoid, add an assert; if the runtime gets this
>	wrong, there's not much point in trying to recover.
>	
>	(Why oh why isn't tm_year just the current year?  I suspect this is
>	a classic example of why "backward compatibility" includes the word
>	"backward".  But as long as we're stuck with it...)

I suspect that the above macro exists because it works regardless of if
you have already adjusted for the date or not.  Thus it returns the correct
year if you say that the current date is 22/07/99 and it returns the correct
year if you say that the current date is 22/07/1999.  Note that the
above macro works with tm_year but also works with true year values as well.

I've seen worse.  I ran into a macro about a year ago which was:

	    ((y) < 100 ? (y) + 1900 : (y))

which is truly and honestly broken after 99.