Re: Macro nesting hell

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Macro nesting hell
Date: 2015-07-01 15:55:48
Message-ID: 20150701155548.GD3289@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Last night my ancient HP compiler spit up on HEAD:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pademelon&dt=2015-07-01%2001%3A30%3A18
> complaining thus:
> cpp: "brin_pageops.c", line 626: error 4018: Macro param too large after substitution - use -H option.
> I was able to revive pademelon by adding a new compiler flag as suggested,
> but after looking at what the preprocessor is emitting, I can't say that
> I blame it for being unhappy. This simple-looking line
>
> Assert(BRIN_IS_REGULAR_PAGE(BufferGetPage(oldbuf)));
>
> is expanding to this:

Wow, that's kind of amazing. I think this particular case boils down to
just PageGetSpecialPointer (bufpage.h) and BufferGetBlock (bufmgr.h).

> I'm thinking we really ought to mount a campaign to replace some of these
> macros with inlined-if-possible functions.

My guess is that changing a very small amount of them will do a large
enough portion of the job.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2015-07-01 16:06:36 Re: Freeze avoidance of very large table.
Previous Message Simon Riggs 2015-07-01 15:28:56 Re: Freeze avoidance of very large table.