Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set

2005-12-01 Thread Bruce Momjian
OK, comments removed, and comment added to port/strtol.c. --- Tom Lane wrote: > Bruce Momjian writes: > > I modified it to: > > errno = 0; /* avoid having to check the result for failure */ > > Just for the record

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set to zero.

2005-12-01 Thread Tom Lane
Martijn van Oosterhout writes: > errno = 0; /* clear prior detected errors */ That one is at least a correct explanation of what the code is doing... regards, tom lane ---(end of broadcast)--- TIP 4: Have you search

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set to zero.

2005-12-01 Thread Tom Lane
Bruce Momjian writes: > I modified it to: > errno = 0; /* avoid having to check the result for failure */ Just for the record, that's *still* wrong. It implies that if we tested (result == LONG_MAX && errno == ERANGE), without zeroing errno beforehand, the code would be correct. But it

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is

2005-12-01 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > If people would like to see a detailed explanation of the > interaction between strtol() and errno, a header comment to pg_strtol() > seems a good place to put it. IMO that is better than copying and > pasting a cryptic one-line comment to each and every ca

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is

2005-12-01 Thread Neil Conway
On Thu, 2005-12-01 at 16:38 -0500, Bruce Momjian wrote: > Maybe it should be: > > errno = 0; /* Allow unconditional errno check */ I think any solution that involves adding more duplication at each strtol() callsite is not great ("Don't Repeat Yourself"). I'd still like to see this ref

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set

2005-12-01 Thread Bruce Momjian
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Thu, Dec 01, 2005 at 04:12:30PM -0500, Bruce Momjian wrote: > > Well, there seems to be enough confusion, even in this email list, that > > identifying _why_ errno is being cleared is a good idea. > > > > I modified it to: > > > >

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set to zero.

2005-12-01 Thread Martijn van Oosterhout
On Thu, Dec 01, 2005 at 04:12:30PM -0500, Bruce Momjian wrote: > Well, there seems to be enough confusion, even in this email list, that > identifying _why_ errno is being cleared is a good idea. > > I modified it to: > > errno = 0; /* avoid having to check the result for failure */ I d

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set to zero.

2005-12-01 Thread Alvaro Herrera
Bruce Momjian wrote: > Tom Lane wrote: > > > or should I add a macro to c.h as: > > > > > /* Sometimes we need to clear errno so we can check errno > > >* without having to check for a failure value from the function > > >* call. > > >*/ > > > #define CLEAR_ERRNO \\ > > > d

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set to zero.

2005-12-01 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Should I just change them all to: > > > errno = 0; /* avoid checking result for failure */ > > No, that's still a completely inaccurate description of the reason > for having the statement. > > > or should I add a macro to c.h as: > > > /* S

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set to zero.

2005-12-01 Thread Tom Lane
Bruce Momjian writes: > Should I just change them all to: > errno = 0; /* avoid checking result for failure */ No, that's still a completely inaccurate description of the reason for having the statement. > or should I add a macro to c.h as: > /* Sometimes we need to clear errno so

Re: [HACKERS] [COMMITTERS] pgsql: Add comments about why errno is set to zero.

2005-12-01 Thread Bruce Momjian
Tom Lane wrote: > [EMAIL PROTECTED] (Bruce Momjian) writes: > > Log Message: > > --- > > Add comments about why errno is set to zero. > > These comments seem a bit wrongheaded, since "checking > LONG_MIN/LONG_MAX" is exactly not what we could do to detect an overflow > error. Yea, I notic