Re: msys inet_pton strangeness - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: msys inet_pton strangeness
Date
Msg-id 66d1fef6-8ad5-4132-8467-591ba4adb97e@dunslane.net
Whole thread Raw
In response to Re: msys inet_pton strangeness  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: msys inet_pton strangeness
List pgsql-hackers
On 2024-09-30 Mo 7:00 AM, Alexander Lakhin wrote:
> Hello Andrew and Thomas,
>
> 29.09.2024 18:47, Andrew Dunstan пишет:
>>
>> I'm inclined to think we might need to reverse the order of the last 
>> two. TBH I don't really understand how this has worked up to now.
>>
>
> I've looked at the last successful run [1] and discovered that
> fe-secure-common.c didn't compile cleanly too:
> ccache gcc ... 
> /home/pgrunner/bf/root/REL_15_STABLE/pgsql.build/../pgsql/src/interfaces/libpq/fe-secure-common.c
> C:/tools/nmsys64/home/pgrunner/bf/root/REL_15_STABLE/pgsql/src/interfaces/libpq/fe-secure-common.c: 
> In function 'pq_verify_peer_name_matches_certificate_ip':
> C:/tools/nmsys64/home/pgrunner/bf/root/REL_15_STABLE/pgsql/src/interfaces/libpq/fe-secure-common.c:219:21: 
> warning: implicit declaration of function 'inet_pton'; did you mean 
> 'inet_aton'? [-Wimplicit-function-declaration]
>   219 |                 if (inet_pton(AF_INET6, host, &addr) == 1)
>       |                     ^~~~~~~~~
>       |                     inet_aton
>
> So it worked just because that missing declaration generated just a
> warning, not an error.



Ah, so this is because gcc 14.1.0 treats this as an error but gcc 12.2.0 
treats it as a warning. Now it makes sense.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: "Daniel Westermann (DWE)"
Date:
Subject: pg_basebackup and error messages dependent on the order of the arguments
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: long-standing data loss bug in initial sync of logical replication