On Thu, 26 Jan 2012, David Schultz wrote:
On Thu, Jan 26, 2012, David Chisnall wrote:
On 26 Jan 2012, at 04:47, Eitan Adler wrote:
What about patching python to only define the POSIX macros iff glibc
is being used (and getting this upstreamed) ?
That's a good strategy regardless. As long as python is doing
something bogus, it could easily break in the future.
Index: include/xlocale.h
[...]
+/*
+ * If people turned off POSIX2008 stuff, but still explicitly included the
+ * xlocale.h header, then assume that they actually do want these functions and
+ * define them.
+ */
+#ifndef __X_LOCALE_DEFINED
+#define __X_LOCALE_DEFINED
+#define LC_COLLATE_MASK (1<<0)
+#define LC_CTYPE_MASK (1<<1)
+#define LC_MESSAGES_MASK (1<<2)
+#define LC_MONETARY_MASK (1<<3)
+#define LC_NUMERIC_MASK (1<<4)
+#define LC_TIME_MASK (1<<5)
+#define LC_ALL_MASK (LC_COLLATE_MASK | LC_CTYPE_MASK | LC_MESSAGES_MASK |
\
+ LC_MONETARY_MASK | LC_NUMERIC_MASK | LC_TIME_MASK)
+#define LC_GLOBAL_LOCALE ((locale_t)-1)
+
+typedef struct _xlocale *locale_t;
+locale_t newlocale(int mask, const char *locale, locale_t base);
+locale_t duplocale(locale_t base);
+int freelocale(locale_t loc);
+const char *querylocale(int mask, locale_t loc);
+locale_t uselocale(locale_t loc);
This file has mounds of style bugs. This change adds many more:
- all tabs after #define are corrupt
- all spaces around the binary operator `<<' are missing.
- the prototype for newlocale() is disordered.
The prototypes have mounds of namespace pollution. All their parameters
have names in the application namespace.
locale.h used to have only 1 corrupt tab after #define (the one, but
now has the above. It also has verbose comments on the prototypes
which make the actual prototypes hard to read. Normally, prototypes
have no comment, as for old prototypes in locale.h. Some of the
comments are not formatted normally.
+
+#endif /* __X_LOCALE_DEFINED */
It would be preferable not to have two copies of all the
definitions and declarations in the source. This is often handled
with separate headers like sys/_timeval.h and sys/_types.h.
Perhaps that's too many hoops to jump through just to cope with
buggy applications. (Incidentally, I noticed that the LC_* macros
are in a slightly different order from the LC_*_MASK macros. For
that reason, and only that reason, it's not possible to define the
latter in terms of the former.)
Would it suffice, perhaps, to simply change the xlocale
declarations to use type `struct _xlocale' instead of locale_t?
That won't fix apps that expect the LC_*_MASK macros to be
defined, but it looks like it will at least make the header
compile in a strict POSIX environment, and it avoids the
duplication.
By the way, struct _xlocale needs another underscore in front of
it. Names prefixed with a single underscore and a lowercase
letter are in the application's namespace.
No, this is not one of the many missing underscores in the above.
Identifiers that begin with a single underscore which is followed by
any character that gives a valid identifier (an upper or lower case
letter, or a digit) are reserved for use as identifiers with file scope
in both the ordinary and tag name spaces. The above only uses _xlocale
in file scope (in a typedef), so application use of it can't clobber
this use. Only use of it in macros is likely to require 2 underscores,
but there is no such use. Using it for only a tag name limits problems
with underscores even more than usual.
Bruce
_______________________________________________
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
