Re: Small changes to facilitate Win32 port - Mailing list pgsql-hackers
From | Dann Corbit |
---|---|
Subject | Re: Small changes to facilitate Win32 port |
Date | |
Msg-id | D90A5A6C612A39408103E6ECDD77B82920CEE3@voyager.corporate.connx.com Whole thread Raw |
In response to | Small changes to facilitate Win32 port (Katherine Ward <kward6@yahoo.com>) |
Responses |
Re: Small changes to facilitate Win32 port
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Thursday, May 30, 2002 3:25 PM > To: Christopher Kings-Lynne > Cc: Katherine Ward; Thomas Lockhart; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Small changes to facilitate Win32 port > > > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > It's more likely that your changes will go through if you > just submit a > > patch! > > I think the question was more directed at "do we like these names?", > which should certainly be asked before going to the trouble > of making a > patch. > > >> 2. Add _P to the following lex/yacc tokens to avoid collisions > >> CONST, CHAR, DELETE, FLOAT, GROUP, IN, OUT > > I'm tempted to suggest that we should stick _P on *all* the > lexer token > symbols, rather than having an inconsistent set of names where some of > them have _P and some do not. Or perhaps _T (for token) > would be a more > sensible convention; I'm not sure why _P was used in the first place. Before you do that, realize that you are violating the implementation's namespace, and your code is therefore not legal ANSI/ISO C. From ISO/IEC 9899:1999 (E) ©ISO/IEC: 7.1.3 Reserved identifiers 1 Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers. - All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. - All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. - Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4). - All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage.154) - Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as a macro name and as an identifier with file scope in the same name space if any of its associated headers is included. > >> 3. Rename two local macros > >> a. MEM_FREE => MEM_FREE_IT in backend/utils/hash/dynahash.c > >> b. IGNORE => IGNORE_TOK in include/utils/datetime.h & > >> backend/utils/adt/datetime.c > > It's fairly amazing that IGNORE is the only one of the > datetime.h field > names that's bitten anyone (so far). Macros named TZ, YEAR, > MONTH, DAY, > HOUR, MINUTE, SECOND, UNITS all look like trouble waiting to happen > (and UNKNOWN_FIELD looks like someone already had to beat a > retreat from > calling it UNKNOWN ;-)). I'm inclined to suggest that these names > should be uniformly changed to DTF_FOO (DTF for "datetime field"). > The macro names appearing before the field name list look like trouble > as well --- anyone have an interest in changing them? Thomas, this is > pretty much your turf; what do you think? > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
pgsql-hackers by date: