Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Andres Freund
On 2017-10-10 18:10:15 -0400, Tom Lane wrote: > Andres Freund writes: > > Here's a fix. Not quite sure whether we really need the > > HAVE_DECL_STRNLEN test, added it for symmetry. > > LGTM. Thanks for checking. > I think the DECL test is a good idea; the system definition

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Tom Lane
Andres Freund writes: > Here's a fix. Not quite sure whether we really need the > HAVE_DECL_STRNLEN test, added it for symmetry. LGTM. I think the DECL test is a good idea; the system definition might be a macro or otherwise weird, in which case we'd cause problems if we

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Andres Freund
On 2017-10-10 17:34:17 -0400, Andrew Dunstan wrote: > This test is governed by the test at line 946 of configure.in. You need > to move it somewhere else. Yea, sorry for the noise :(. Greetings, Andres Freund -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Andres Freund
On 2017-10-10 13:53:15 -0700, Andres Freund wrote: > On 2017-10-10 16:51:39 -0400, Tom Lane wrote: > > Andres Freund writes: > > > As far as I can tell it's still somehow using a configure from before > > > the last commits: > > > > No, it's pilot error. The AC_CHECK_FUNCS

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Andrew Dunstan
On 10/10/2017 03:48 PM, Andres Freund wrote: > On 2017-10-09 23:33:36 -0400, Andrew Dunstan wrote: >> >> On 10/09/2017 07:15 PM, Andres Freund wrote: >>> Hi Andrew, >>> >>> On 2017-10-09 22:22:04 +, Andres Freund wrote: Add pg_strnlen() a portable implementation of strlen. As

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Andres Freund
On 2017-10-10 16:51:39 -0400, Tom Lane wrote: > Andres Freund writes: > > As far as I can tell it's still somehow using a configure from before > > the last commits: > > No, it's pilot error. The AC_CHECK_FUNCS call you added strnlen to > is only executed if > AS_IF([test

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Tom Lane
Andres Freund writes: > As far as I can tell it's still somehow using a configure from before > the last commits: No, it's pilot error. The AC_CHECK_FUNCS call you added strnlen to is only executed if AS_IF([test "$enable_thread_safety" = yes -a "$PORTNAME" != "win32"], A

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Andres Freund
On 2017-10-10 16:37:04 -0400, Tom Lane wrote: > Andres Freund writes: > > (there's definitely fixes to be made to where strnlen's replacement is > > located, but regardless, this needs to be fixed too) > > Given that strnlen is standardized by POSIX, and has been for nigh a >

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Tom Lane
Andres Freund writes: > (there's definitely fixes to be made to where strnlen's replacement is > located, but regardless, this needs to be fixed too) Given that strnlen is standardized by POSIX, and has been for nigh a decade, I think it'd be all right for us to treat it as a

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-10 Thread Andres Freund
On 2017-10-09 23:33:36 -0400, Andrew Dunstan wrote: > > > On 10/09/2017 07:15 PM, Andres Freund wrote: > > Hi Andrew, > > > > On 2017-10-09 22:22:04 +, Andres Freund wrote: > >> Add pg_strnlen() a portable implementation of strlen. > >> > >> As the OS version is likely going to be more

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-09 Thread Tom Lane
Andres Freund writes: > I think the current split between common and port isn't particularly > meaningful. But as long as we have it, this probably belongs more in > port than in common. Well, port is supposed to be for stuff that we expect to find in libc on common

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-09 Thread Andres Freund
On 2017-10-10 00:25:52 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > frogmouth is using some code not yet released that makes the config > > cache persistent. I just identified and fixed a stupid bug in the code > > that obsoletes the cache, and I have removed

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-09 Thread Tom Lane
Andrew Dunstan writes: > frogmouth is using some code not yet released that makes the config > cache persistent. I just identified and fixed a stupid bug in the code > that obsoletes the cache, and I have removed frogmouth's cache file and > set it running again, so we'll see

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-09 Thread Andrew Dunstan
On 10/09/2017 07:15 PM, Andres Freund wrote: > Hi Andrew, > > On 2017-10-09 22:22:04 +, Andres Freund wrote: >> Add pg_strnlen() a portable implementation of strlen. >> >> As the OS version is likely going to be more optimized, fall back to >> it if available, as detected by configure. > I'm

Re: [COMMITTERS] pgsql: Add pg_strnlen() a portable implementation of strlen.

2017-10-09 Thread Andres Freund
Hi Andrew, On 2017-10-09 22:22:04 +, Andres Freund wrote: > Add pg_strnlen() a portable implementation of strlen. > > As the OS version is likely going to be more optimized, fall back to > it if available, as detected by configure. I'm a bit confused, frogmouth