On Tue, Mar 10, 2020 at 12:22:32AM +, Smith, Peter wrote:
> Sorry I was AWOL for a couple of months. Thanks for taking the patch
> further, and committing it.
No problem, I am glad to see you around.
--
Michael
signature.asc
Description: PGP signature
Hi Michael,
Sorry I was AWOL for a couple of months. Thanks for taking the patch further,
and committing it.
Kind Regards
---
Peter Smith
Fujitsu Australia
On Fri, Jan 31, 2020 at 02:46:16PM +0900, Michael Paquier wrote:
> Actually, thinking more about it, I'd rather remove this part as well,
> keeping only the change in the third paragraph of this comment block.
I have tweaked a bit the comments in this area, and applied the
patch. I'll begin a new
On Fri, Jan 31, 2020 at 02:15:42PM +0900, Kyotaro Horiguchi wrote:
> As a cross check, it cleanly applied and worked as expected. The
> fallback definition of StaticAssertDecl for C worked for gcc 8.3.
Thanks for the review.
> - * Macros to support compile-time assertion checks.
> + * Macros to s
At Fri, 31 Jan 2020 11:47:01 +0900, Michael Paquier wrote
in
> On Tue, Dec 24, 2019 at 02:47:29PM +0900, Michael Paquier wrote:
> > I am still seeing that a couple of points need an extra lookup:
> > - Addition of a Decl() in at least one header of the core code.
>
> I agree with the addition o
On Tue, Dec 24, 2019 at 02:47:29PM +0900, Michael Paquier wrote:
> I am still seeing that a couple of points need an extra lookup:
> - Addition of a Decl() in at least one header of the core code.
I agree with the addition of Decl() definition in a header, and could
not think about something bette
On Fri, Dec 20, 2019 at 01:08:47AM +, Smith, Peter wrote:
> I updated the most recent patch (_5 from Michael) so it now has your
> suggested error message rewording.
Hmm. Based on the last messages, and this one in particular:
https://www.postgresql.org/message-id/20191202155545.yzbfzuppjriti
On Wed, Dec 04, 2019 at 09:54:47AM -0800, Andres Freund wrote:
> Well, _Static_assert has an error message, so we got to pass
> something. And having something like "array length mismatch", without
> referring again to the variable, doesn't strike me as that bad. We could
> of course just again pas
Hello Michael,
> In short, attached is an updated version of your patch which attempts to
> solve that. I have tested this with some cplusplus stuff, and GCC for both
> versions (static_assert is available in GCC >= 6, but a manual change of c.h
> does the trick).
> I have edited the patch a b
-Original Message-
From: Andres Freund Sent: Tuesday, 3 December 2019 2:56 AM
> +StaticAssertDecl(lengthof(LockTagTypeNames) == (LOCKTAG_ADVISORY + 1),
> + "LockTagTypeNames array inconsistency");
> +
>
>These error messages strike me as somewhat unhelpful. I'd
Hi,
On 2019-12-04 10:09:28 +0100, Peter Eisentraut wrote:
> On 2019-12-02 16:55, Andres Freund wrote:
> > > +StaticAssertDecl(lengthof(LockTagTypeNames) == (LOCKTAG_ADVISORY + 1),
> > > + "LockTagTypeNames array inconsistency");
> > > +
> > These error messages strike me a
On 2019-12-04 15:16:25 +0900, Michael Paquier wrote:
> On Mon, Dec 02, 2019 at 07:55:45AM -0800, Andres Freund wrote:
> > Now that I'm back from vacation, I'll try to take a stab at b). It
> > should definitely doable to use the same approach for StaticAssertStmt,
> > the problematic case might be
On 2019-12-02 16:55, Andres Freund wrote:
+StaticAssertDecl(lengthof(LockTagTypeNames) == (LOCKTAG_ADVISORY + 1),
+"LockTagTypeNames array inconsistency");
+
These error messages strike me as somewhat unhelpful. I'd probably just
reword them as "array length misma
On Mon, Dec 02, 2019 at 07:55:45AM -0800, Andres Freund wrote:
> On 2019-11-29 11:11:25 +0900, Michael Paquier wrote:
>> diff --git a/src/include/c.h b/src/include/c.h
>> index 00e41ac546..91d6d50e76 100644
>> --- a/src/include/c.h
>> +++ b/src/include/c.h
>> [...]
>
> I think this a) needs an upd
Hi,
On 2019-11-29 11:11:25 +0900, Michael Paquier wrote:
> On Wed, Nov 27, 2019 at 12:23:33PM +, Smith, Peter wrote:
> > * That is beyond the scope for what I wanted my patch to achieve; my
> > * use-cases are C code only.
I really don't think that's justification enough for having diverging
On Wed, Nov 27, 2019 at 12:23:33PM +, Smith, Peter wrote:
> * That is beyond the scope for what I wanted my patch to achieve; my
> * use-cases are C code only.
Well, FWIW, I do have some extensions using __cplusplus and I am
pretty sure that I am not the only one with that. The thing is that
> It seems to me that there is a good point to be consistent with the treatment
> of StaticAssertStmt and StaticAssertExpr in c.h, which have fallback
> implementations in *all* the configurations supported.
Consistency is good, but:
* That is beyond the scope for what I wanted my patch to achi
Hi Andres,
>>> As far as I can tell we should be able to use the prototype based approach
>>> in all the cases where we currently use the "negative bit-field width"
>>> approach?
>> ...
>> But I did not refactor existing code to use the new way because I was
>> fearful that there might be some
Hi,
On 2019-11-13 03:23:06 +, Smith, Peter wrote:
> From: Andres Freund Sent: Wednesday, 13 November 2019
> 6:01 AM
>
> >Peter Smith:
> >
> > Is there a reason to not just make StaticAssertExpr and StaticAssertStmt be
> > the same? I don't want to proliferate variants that users have to
>
On 2019-11-12 20:00, Andres Freund wrote:
Looking at the cplusplus variant, I'm somewhat surprised to see that you
made both fallback and plain version unconditionally use GCC style
compound expressions:
Was that intentional? The C version intentionally uses compound
expressions only for the _
From: Andres Freund Sent: Wednesday, 13 November 2019 6:01
AM
>Peter Smith:
>
> Is there a reason to not just make StaticAssertExpr and StaticAssertStmt be
> the same? I don't want to proliferate variants that users have to understand
> if there's no compelling
> need. Nor do I think do we r
Hi Peter, Peter, :)
On 2019-10-28 00:30:11 +, Smith, Peter wrote:
> From: Andres Freund Sent: Sunday, 27 October 2019 12:03
> PM
> > My proposal for this really was just to use this as a fallback for when
> > static assert isn't available. Which in turn I was just suggesting because
> > T
On Mon, Oct 28, 2019 at 03:42:02AM +, Smith, Peter wrote:
> From: Kyotaro Horiguchi Sent: Monday, 28 October
> 2019 1:26 PM
>> It is missing the __cplusplus case?
>
> My use cases for the macro are only in C code, so that's all I was interested
> in at this time.
> If somebody else wants to
From: Kyotaro Horiguchi Sent: Monday, 28 October 2019
1:26 PM
> It is missing the __cplusplus case?
My use cases for the macro are only in C code, so that's all I was interested
in at this time.
If somebody else wants to extend the patch for C++ also (and test it) they can
do.
Kind Regards,
From: Andres Freund Sent: Sunday, 27 October 2019 12:03 PM
> My proposal for this really was just to use this as a fallback for when
> static assert isn't available. Which in turn I was just suggesting because
> Tom wanted a fallback.
The patch is updated to use "extern" technique only when "_
On 2019-10-27 11:44:54 +, Smith, Peter wrote:
> From: Andres Freund Sent: Sunday, 27 October 2019 12:03
> PM
> > I think it should work everywhere that has static assert. So we should need
> > a separate configure check.
>
> Er, that's a typo right? I think you meant: "So we *shouldn't* nee
From: Andres Freund Sent: Sunday, 27 October 2019 12:03 PM
>>Ideally, the implementation should end up calling _Static_assert()
>>somehow, so that we get the compiler's native error message.
OK. I can work on that.
>>We could do a configure check for whether _Static_assert() works at
>>file s
Hi,
On October 26, 2019 6:06:07 AM PDT, Peter Eisentraut
wrote:
>On 2019-10-10 00:52, Smith, Peter wrote:
>> I liked your idea of using an extern function declaration for
>implementing the file-scope compile-time asserts. AFAIK it is valid
>standard C.
>>
>> Thank you for the useful link to th
On 2019-10-10 00:52, Smith, Peter wrote:
> I liked your idea of using an extern function declaration for implementing
> the file-scope compile-time asserts. AFAIK it is valid standard C.
>
> Thank you for the useful link to that compiler explorer. I tried many
> scenarios of the new StaticAssert
From: Andres Freund Sent: Tuesday, 1 October 2019 3:14 AM
>I wonder if defining the fallback static assert code to something like
> extern void static_assert_func(int static_assert_failed[(condition) ? 1 :
> -1]); isn't a solution, however. I *think* that's standard C. Seems to work
> at least
Hi,
On September 30, 2019 10:20:54 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On 2019-09-19 04:46:27 +, Smith, Peter wrote:
>>> In the attached patch example I have defined a new macro
>>> StaticAssertDecl. A typical usage of it is shown in the relpath.c
>>> file.
>
>> I'm in favor o
Andres Freund writes:
> On 2019-09-19 04:46:27 +, Smith, Peter wrote:
>> In the attached patch example I have defined a new macro
>> StaticAssertDecl. A typical usage of it is shown in the relpath.c
>> file.
> I'm in favor of adding that - in fact, when I was working on adding a a
> static_as
Hi,
On 2019-09-19 04:46:27 +, Smith, Peter wrote:
> In the attached patch example I have defined a new macro
> StaticAssertDecl. A typical usage of it is shown in the relpath.c
> file.
I'm in favor of adding that - in fact, when I was working on adding a a
static_assert wrapper, I was advocat
-Original Message-
From: Michael Paquier Sent: Thursday, 19 September 2019
11:08 AM
>On Wed, Sep 18, 2019 at 04:46:30PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> Postgres doesn't seem to have it, but it would be possible to define a
>> StaticAssertDecl macro that can be used at the file
At Thu, 19 Sep 2019 10:07:40 +0900, Michael Paquier wrote
in <20190919010740.gc22...@paquier.xyz>
> On Wed, Sep 18, 2019 at 04:46:30PM +0100, Dagfinn Ilmari Mannsåker wrote:
> > Postgres doesn't seem to have it, but it would be possible to define a
> > StaticAssertDecl macro that can be used at t
On Wed, Sep 18, 2019 at 04:46:30PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Postgres doesn't seem to have it, but it would be possible to define a
> StaticAssertDecl macro that can be used at the file level, outside any
> function. See for example Perl's STATIC_ASSERT_DECL:
>
> https://github.com
-Original Message-
From: Michael Paquier Sent: Wednesday, 18 September 2019
5:40 PM
> For some of them it could help, and we could think about a better location
> for that stuff than an unused routine. The indentation of your patch is
> weird, with "git diff --check" complaining a lo
Michael Paquier writes:
> On Wed, Sep 18, 2019 at 06:46:24AM +, Smith, Peter wrote:
>> I have identified some OSS code where more compile-time asserts could be
>> added.
>>
>> Mostly these are asserting that arrays have the necessary length to
>> accommodate the enums that are used to inde
On Wed, Sep 18, 2019 at 06:46:24AM +, Smith, Peter wrote:
> I have identified some OSS code where more compile-time asserts could be
> added.
>
> Mostly these are asserting that arrays have the necessary length to
> accommodate the enums that are used to index into them.
>
> In general the
39 matches
Mail list logo
