On Wed, Nov 30, 2005 at 02:01:46PM -0500, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > Any preferences on an approach? The simplest and easiest to verify
> > would be to raise an error for just this particular case; a TODO
> > item might be to change how the string is parsed to allow values
> > larger than LONG_MAX.
>
> I think the latter would be a feature enhancement and therefore not
> good material to back-patch. Just erroring out seems appropriate
> for now.
Agreed. I'm thinking about rewriting strtol() calls in datetime.c
to look like this:
errno = 0; val = strtol(field[i], &cp, 10); if (errno == ERANGE) return DTERR_FIELD_OVERFLOW;
Does that look okay? Or would you rather raise an error with ereport()?
> > I see several calls to strtol() that aren't checked for overflow but
> > that might not be relevant to this problem, so I'm thinking this patch
> > ought not touch them. Maybe that's another TODO item.
>
> If it's possible for them to be given overflowing input, they probably
> ought to be checked.
I'm looking at all the strtol() calls in datetime.c right now; I
haven't looked anywhere else yet. Should I bother checking values
that will be range checked later anyway? Time zone displacements,
for example?
--
Michael Fuhr
