Re: fix_PGSTAT_NUM_TABENTRIES_macro patch
От | Tom Lane |
---|---|
Тема | Re: fix_PGSTAT_NUM_TABENTRIES_macro patch |
Дата | |
Msg-id | 20782.1388708463@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fix_PGSTAT_NUM_TABENTRIES_macro patch (Mark Dilger <markdilger@yahoo.com>) |
Список | 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 по дате отправления: