Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group