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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Add pg_strnlen() a portable implementation of strlen.
Date: 2017-10-10 04:42:53
Message-ID: 20171010044253.yq7eiczk5ixomhpb@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On 2017-10-10 00:25:52 -0400, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> 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 if that fixes things.

Interesting. Although an outdated cache file doesn't explain why
configure didn't even do the relevant check, no? This kinda sounds more
like configure as a whole is outdated, rather than it's cache file.

> I doubt it.

It'll quite possibly fix it, but probably not for good reasons.
Presumably after a proper configure run the fallback won't be used
anymore.

> I think the problem with this patch is that Andres has
> made libpgport dependent on libpgcommon, which is backwards, or at
> least circular. The module layering is supposed to go the other way.

Yes, quite possibly. At least one platform without strnlen [1], as well
as my local machine when intentionally marking strnlen as not available,
ran successfully. But that's likely just a difference in how/when
symbols are resolved.

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.

Greetings,

Andres Freund

[1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=gharial&dt=2017-10-10%2000%3A31%3A38&stg=config

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-10-10 04:55:14 Re: pgsql: Add pg_strnlen() a portable implementation of strlen.
Previous Message Tom Lane 2017-10-10 04:25:52 Re: pgsql: Add pg_strnlen() a portable implementation of strlen.