Thomas Munro writes:
> Cool. I was wondering if it was going to break on some of our recent
> POSIX 2008 stuff (thread-safe bits and pieces) next, given
> _POSIX_C_SOURCE=200112L. It certainly does know about 2008 too, so it
> looks like the man page might be out of date.
Do you want to try se
On Wed, Dec 4, 2024 at 5:33 PM Tom Lane wrote:
> hake didn't like that, but after adding -D__EXTENSIONS__ per
> https://illumos.org/man/7/standards
> it seems happy again. Its configure results are the same as
> beforehand, and the warning about shmdt() is gone.
Cool. I was wondering if it was
I wrote:
> Pushed; I'll await hake's next run with interest.
hake didn't like that, but after adding -D__EXTENSIONS__ per
https://illumos.org/man/7/standards
it seems happy again. Its configure results are the same as
beforehand, and the warning about shmdt() is gone.
reg
Andres Freund writes:
> On 2024-12-02 17:42:33 -0500, Tom Lane wrote:
>> I'll proceed with improving that (in master only, don't think we need it in
>> back branches, at least not today) unless somebody pushes back soon.
> +1
Pushed; I'll await hake's next run with interest.
Thomas Munro writes:
> Why do we bother with a "Pointer" type? The idiomatic way to do
> byte-oriented pointer arithmetic is to cast to char *, or uint8_t*
> etc, which doesn't require the reader to go and figure out what stride
> that non-standard type name implies.
I think getting rid of Point
On Tue, Oct 29, 2024 at 9:06 PM Peter Eisentraut wrote:
> There are a bunch of (void *) casts in the code that don't make sense to
> me. I think some of these were once necessary because char * was used
> in place of void * for some function arguments.
Some other places that sprang to my eye rec
On 2024-12-02 17:42:33 -0500, Tom Lane wrote:
> I'll proceed with improving that (in master only, don't think we need it in
> back branches, at least not today) unless somebody pushes back soon.
+1
Andres Freund writes:
> On 2024-12-02 17:11:30 -0500, Tom Lane wrote:
>> I'm inclined to propose adding something like
>> CPPFLAGS="$CPPFLAGS -D_POSIX_C_SOURCE=200112L"
>> to src/template/solaris. Not sure if we have a corresponding
>> mechanism for meson, though.
> elif host_system == 'sunos'
>
Hi,
On 2024-12-02 17:11:30 -0500, Tom Lane wrote:
> I'm inclined to propose adding something like
>
> CPPFLAGS="$CPPFLAGS -D_POSIX_C_SOURCE=200112L"
>
> to src/template/solaris. Not sure if we have a corresponding
> mechanism for meson, though.
elif host_system == 'sunos'
portname = 'solaris
Thomas Munro writes:
> I wouldn't change that. illumos is selecting the old pre-standard
> declaration here, but it knows the standard one:
> https://github.com/illumos/illumos-gate/blob/27ecbff00d8c86a2647d6fe325cacb220d712115/usr/src/uts/common/sys/shm.h#L129
> https://illumos.org/man/2/shmdt
Peter Eisentraut writes:
> Committed, thanks.
Now that we have a more-or-less full set of buildfarm results
on this, I checked for new warnings, and found two:
pg_shmem.c: In function 'PGSharedMemoryIsInUse':
pg_shmem.c:323:33: warning: passing argument 1 of 'shmdt' from incompatible
pointer ty
On Tue, Dec 3, 2024 at 7:06 AM Tom Lane wrote:
> This is from hake[1], which is running OpenIndiana/illumos.
> That platform shows a couple of other strange warnings, so maybe
> re-eliminating these two is not worth worrying about, but
> nonetheless the casts to void * were doing something here.
On 28.11.24 04:54, Andreas Karlsson wrote:
On 11/14/24 9:59 AM, Peter Eisentraut wrote:
I'm more concerned that many of these just keep getting copied around
indiscriminately, and this is liable to hide actual type mismatches or
silently discard qualifiers. So I'm arguing in favor of a more
r
On 11/14/24 9:59 AM, Peter Eisentraut wrote:
I'm more concerned that many of these just keep getting copied around
indiscriminately, and this is liable to hide actual type mismatches or
silently discard qualifiers. So I'm arguing in favor of a more
restrictive style in this matter.
+1 I agre
On Thu, Nov 14, 2024 at 09:59:07AM +0100, Peter Eisentraut wrote:
> On 29.10.24 15:20, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > There are a bunch of (void *) casts in the code that don't make sense to
> > > me. I think some of these were once necessary because char * was used
> > > in p
On 29.10.24 15:20, Tom Lane wrote:
Peter Eisentraut writes:
There are a bunch of (void *) casts in the code that don't make sense to
me. I think some of these were once necessary because char * was used
in place of void * for some function arguments. And some of these were
probably just copie
On Tue, Oct 29, 2024 at 10:20:03AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > There are a bunch of (void *) casts in the code that don't make sense to
> > me. I think some of these were once necessary because char * was used
> > in place of void * for some function arguments. And so
Peter Eisentraut writes:
> There are a bunch of (void *) casts in the code that don't make sense to
> me. I think some of these were once necessary because char * was used
> in place of void * for some function arguments. And some of these were
> probably just copied around without further th
18 matches
Mail list logo
