Re: fix_PGSTAT_NUM_TABENTRIES_macro patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
Date
Msg-id 20782.1388708463@sss.pgh.pa.us
Whole thread Raw
In response to Re: fix_PGSTAT_NUM_TABENTRIES_macro patch  (Mark Dilger <markdilger@yahoo.com>)
List pgsql-hackers
Mark Dilger <markdilger@yahoo.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Store Extension Options
Next
From: Robert Haas
Date:
Subject: Re: truncating pg_multixact/members