On tis, 2012-03-20 at 15:04 -0400, Tom Lane wrote:
> Hm. I bet it thinks that PG_USED_FOR_ASSERTS_ONLY is the variable
> name, which means that the behavior might be more exciting for
> multi-word type names (for instance "struct foo" or "volatile int *".
> Could you check a few cases like that?
Peter Eisentraut writes:
> As you can see, pgindent adds whitespace on top of #ifdef
> USE_ASSERT_CHECKING, and messes up the vertical alignment of variable
> definitions that contain extra attributes.
Hm. I bet it thinks that PG_USED_FOR_ASSERTS_ONLY is the variable name,
which means that the b
On tis, 2012-01-24 at 13:18 -0500, Tom Lane wrote:
> Robert Haas writes:
> > Yes, that's what I meant when I suggested it originally. I'm just not
> > sure it's any nicer than adding ifdefs for USE_ASSERT_CHECKING.
>
> I'm inclined to think that it probably is nicer, just because of less
> verti
Robert Haas writes:
> Yes, that's what I meant when I suggested it originally. I'm just not
> sure it's any nicer than adding ifdefs for USE_ASSERT_CHECKING.
I'm inclined to think that it probably is nicer, just because of less
vertical space used. But again, this opinion is contingent on what
On Tue, Jan 24, 2012 at 1:03 PM, Tom Lane wrote:
> I wrote:
>> Also, it occurs to me that an intermediate macro
>> "PG_USED_FOR_ASSERTS_ONLY" would be a good idea, first because it
>> documents *why* you want to mark the variable as possibly unused,
>> and second because changing the macro definit
I wrote:
> Also, it occurs to me that an intermediate macro
> "PG_USED_FOR_ASSERTS_ONLY" would be a good idea, first because it
> documents *why* you want to mark the variable as possibly unused,
> and second because changing the macro definition would provide an easy way
> to check for totally-unu
Robert Haas writes:
> On Tue, Jan 24, 2012 at 12:12 PM, Tom Lane wrote:
>> Ouch. Is it really true that __attribute__((unused)) disables detection
>> of use of uninitialized variables?
> Oh, I think maybe I am confused. The downsides of disabling *unused*
> variable detection are obviously much
On Tue, Jan 24, 2012 at 12:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> Spraying the code with __attribute__((unused)) is somewhat undesirable
>> because it could mask a failure to properly initialize the variable in
>> an assert-enabled build.
>
> Ouch. Is it really true that __attribute__((
Robert Haas writes:
> Spraying the code with __attribute__((unused)) is somewhat undesirable
> because it could mask a failure to properly initialize the variable in
> an assert-enabled build.
Ouch. Is it really true that __attribute__((unused)) disables detection
of use of uninitialized variabl
On Sat, Jan 21, 2012 at 1:06 PM, Peter Eisentraut wrote:
> So, here are three patches that could solve this issue.
>
> pg-cassert-unused-attribute.patch, the one I already showed, using
> __attribute__((unused).
>
> pg-cassert-unused-ifdef.patch, using only additional #ifdef
> USE_ASSERT_CHECKING.
On ons, 2012-01-18 at 21:16 +0200, Peter Eisentraut wrote:
> On sön, 2012-01-15 at 08:14 -0500, Andrew Dunstan wrote:
> > It would possibly have some documentary value too. Just looking very
> > quickly at Peter's patch, I don't really understand his assertion that
> > this would significantly but
Peter Eisentraut writes:
> On sön, 2012-01-15 at 01:37 -0500, Tom Lane wrote:
>> Surely this will fail entirely on most non-gcc compilers?
> No, because __attribute__() is defined to empty for other compilers. We
> use this pattern already.
Oh, duh. In that case my only objection to doing it
On sön, 2012-01-15 at 08:14 -0500, Andrew Dunstan wrote:
> It would possibly have some documentary value too. Just looking very
> quickly at Peter's patch, I don't really understand his assertion that
> this would significantly butcher the code. The worst effect would be
> that in a few cases we'
On sön, 2012-01-15 at 01:37 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > I see that in some places our code already uses #ifdef
> > USE_ASSERT_CHECKING, presumably to hide similar issues. But in most
> > cases using this would significantly butcher the code. I found that
> > adding __at
On Sun, Jan 15, 2012 at 1:14 PM, Andrew Dunstan wrote:
>
>
> On 01/15/2012 01:37 AM, Tom Lane wrote:
>>
>> Peter Eisentraut writes:
>>>
>>> I see that in some places our code already uses #ifdef
>>> USE_ASSERT_CHECKING, presumably to hide similar issues. But in most
>>> cases using this would si
On 01/15/2012 01:37 AM, Tom Lane wrote:
Peter Eisentraut writes:
I see that in some places our code already uses #ifdef
USE_ASSERT_CHECKING, presumably to hide similar issues. But in most
cases using this would significantly butcher the code. I found that
adding __attribute__((unused)) is c
Peter Eisentraut writes:
> I see that in some places our code already uses #ifdef
> USE_ASSERT_CHECKING, presumably to hide similar issues. But in most
> cases using this would significantly butcher the code. I found that
> adding __attribute__((unused)) is cleaner. Attached is a patch that
> c
In builds without --enable-cassert (I guess not many developers use
those a lot), there are quite a few unused variable warnings. These
usually hold some intermediate result that the assert checks later. I
see that in some places our code already uses #ifdef
USE_ASSERT_CHECKING, presumably to hid
18 matches
Mail list logo
