Re: fix_PGSTAT_NUM_TABENTRIES_macro patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <markdilger(at)yahoo(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Date: 2014-01-03 00:21:03
Message-ID: 20782.1388708463@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Dilger <markdilger(at)yahoo(dot)com> writes:
> The mechanism that occurs to me (and I'm not wedded to
> this idea) is:

> typedef uint8 T_HOFF_TYPE;
> typedef struct xl_heap_header
> {
> uint16 t_infomask2;
> uint16 t_infomask;
> T_HOFF_TYPE t_hoff;
> } xl_heap_header;

> #define SizeOfHeapHeader (offsetof(xl_heap_header, t_hoff) + sizeof(T_HOFF_TYPE))

Meh. That does nothing for the "add a field in the wrong place" risk.
Yes, it would prevent people from changing the type of t_hoff without
updating the macro --- but I'm not convinced that defending against that
alone is worth any notational pain. If you're changing t_hoff's type
without looking fairly closely at every reference to t_hoff, you're
practicing unsafe programming to begin with.

I wonder though if we could invent a macro that produces the sizeof
a struct field, and then use that in macros like this. Something like

#define field_sizeof(typename, fieldname) \
sizeof(((typename *) NULL)->fieldname)

Compare the default definition of offsetof ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-01-03 01:19:23 Re: truncating pg_multixact/members
Previous Message Robert Haas 2014-01-03 00:16:55 Re: [PATCH] Store Extension Options