Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
Date: 2009-05-28 15:57:39
Message-ID: 10902.1243526259@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Meskes <meskes(at)postgresql(dot)org> writes:
> I have to admit that those version look strikingly unsimilar to me. There is no
> reference to Rhs[N] in our macro at all. But then I have no idea whether this
> is needed.

The default version of the macro is intended to track both the starting
and ending locations of every construct. Our simplified version only
tracks the starting locations. The inputs are RHS[k], the location
values for the constituent elements of the current production, and
the output is the location value for the construct being formed.
In the default version, you naturally want to copy the start of
RHS[1] and the end of RHS[N], where N is the number of production
elements. In ours, we just copy the location of RHS[1]. However,
both macros need a special case for empty productions (with N = 0).

AFAICS, Sun's compiler is just too stupid and shouldn't be emitting
this warning. Perhaps the right response is to file a bug report
against the compiler.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-05-28 16:06:13 Re: Clean shutdown and warm standby
Previous Message Greg Stark 2009-05-28 15:57:16 Re: User-facing aspects of serializable transactions