Hi Tom,
Since no one seems to be particularly excited about this patch I'm
marking it as "Returned with feedback" to save reviewers time.
On Wed, Mar 15, 2017 at 12:21:21PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Mar 15, 2017 at 10:57:15AM -0400, Tom Lane
On 3/13/17 11:35, Aleksander Alekseev wrote:
> Here is a new patch. I tried to make as little changes as possible. This
> is no doubt not the most beautiful patch on Earth but it removes all
> warnings. I anyone could suggest an approach that would be significantly
> better please don't hesitate
Noah Misch writes:
> On Wed, Mar 15, 2017 at 12:04:11PM +0300, Aleksander Alekseev wrote:
>> If it no too much trouble could you please explain what will happen
>> on such platforms?
> Both port.h and a system header will furnish a strlcpy() declaration. The #if
> you
This mailing list does not welcome top-post replies.
On Wed, Mar 15, 2017 at 12:04:11PM +0300, Aleksander Alekseev wrote:
> > This is wrong on platforms that do have strlcpy() in libc.
>
> If it no too much trouble could you please explain what will happen
> on such platforms?
Both port.h and a
Noah Misch writes:
> On Wed, Mar 15, 2017 at 10:57:15AM -0400, Tom Lane wrote:
>> Seems like the correct solution is to
>> absorb that fix, either by updating to a newer autoconf release or by
>> carrying our own version of AC_CHECK_DECLS until they come out with one.
> As you
On Wed, Mar 15, 2017 at 10:57:15AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Mar 13, 2017 at 06:35:53PM +0300, Aleksander Alekseev wrote:
> >> + * Unfortunately in case of strlcat and strlcpy we can't trust tests
> >> + * executed by Autotools if Clang > 3.6 is
Noah Misch writes:
> On Mon, Mar 13, 2017 at 06:35:53PM +0300, Aleksander Alekseev wrote:
>> + * Unfortunately in case of strlcat and strlcpy we can't trust tests
>> + * executed by Autotools if Clang > 3.6 is used.
> This is wrong on platforms that do have strlcpy() in libc.
Hi Hoah.
Thanks a lot for a reply!
> This is wrong on platforms that do have strlcpy() in libc.
If it no too much trouble could you please explain what will happen
on such platforms? On what platform did you check it? I'm sure it
fixable. And I got a strong feeling that "wrong" could be a bit
On Mon, Mar 13, 2017 at 06:35:53PM +0300, Aleksander Alekseev wrote:
> --- a/src/include/port.h
> +++ b/src/include/port.h
> @@ -395,11 +395,22 @@ extern double rint(double x);
> extern int inet_aton(const char *cp, struct in_addr * addr);
> #endif
>
> -#if !HAVE_DECL_STRLCAT
> +/*
> + *
Hi David,
Thank you for reminding about this patch!
Here is a new patch. I tried to make as little changes as possible. This
is no doubt not the most beautiful patch on Earth but it removes all
warnings. I anyone could suggest an approach that would be significantly
better please don't hesitate
Hi Aleksander,
On 2/22/17 9:43 AM, Fabien COELHO wrote:
>
> Hello Aleksander,
>
>> ```
>> xloginsert.c:742:18: warning: implicit conversion from 'int' to 'char'
>> changes value from 253 to -3 [-Wconstant-conversion]
>> ```
>
> There is a bunch of these in "xlog.c" as well, and the same code
Hello Aleksander,
```
xloginsert.c:742:18: warning: implicit conversion from 'int' to 'char'
changes value from 253 to -3 [-Wconstant-conversion]
```
There is a bunch of these in "xlog.c" as well, and the same code is used
in "pg_resetwal.c".
Patch that fixes these warnings is attached
Tomas Vondra writes:
> On 02/20/2017 04:37 PM, Tom Lane wrote:
>> But that's using gcc. Perhaps clang behaves differently?
> AFAIK it happens because clang treats missing declarations as warnings,
> which confuses configure:
>
On 02/20/2017 04:37 PM, Tom Lane wrote:
Aleksander Alekseev writes:
In theory - could we just always use our internal strl* implementations?
Hmm, maybe configure's test to see if a declaration has been provided
is going wrong? I notice that anchovy, which is
Aleksander Alekseev writes:
> In theory - could we just always use our internal strl* implementations?
Hmm, maybe configure's test to see if a declaration has been provided
is going wrong? I notice that anchovy, which is supposedly current
Arch Linux, doesn't think
In theory - could we just always use our internal strl* implementations?
On Mon, Feb 20, 2017 at 09:26:44AM -0500, Tom Lane wrote:
> Aleksander Alekseev writes:
> > I've just tried to build PostgreSQL with Clang 3.9.1 (default version
> > currently available in Arch
Aleksander Alekseev writes:
> I've just tried to build PostgreSQL with Clang 3.9.1 (default version
> currently available in Arch Linux) and noticed that it outputs lots of
> warning messages. Most of them are result of a bug in Clang itself:
>
> postinit.c:846:3:
Hello.
I've just tried to build PostgreSQL with Clang 3.9.1 (default version
currently available in Arch Linux) and noticed that it outputs lots of
warning messages. Most of them are result of a bug in Clang itself:
```
postinit.c:846:3: note: include the header or explicitly
provide a
18 matches
Mail list logo