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
Dear Hackers,
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 code is already commented with warnings such as:
* "If you ad
40 matches
Mail list logo
