[Bug regex/1236] New: regex.h violates POSIX name space rules in several places

[Bug regex/1236] New: regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

I noticed quite a few violations of POSIX namespace rules in regex.h,
and wrote a patch to fix them all.  POSIX says that regex.h's extensions
must start with re_ or rm_ or end with _t, or be macros that start with
REG_.  It also says that users can undef the REG_ macros without breaking
anything.  libc regex.h violates these rules in many places.

The attached patch fixes regex.h so that it obeys the POSIX name space
rules if the appropriate feature-test macros are defined.  There is no
change in the usual case.  The ABI is not affected.

-- 
           Summary: regex.h violates POSIX name space rules in several
                    places
           Product: glibc
           Version: 2.3.5
            Status: NEW
          Severity: normal
          Priority: P2
         Component: regex
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: eggert at gnu dot org
                CC: glibc-bugs-regex at sources dot redhat dot com,glibc-
                    bugs at sources dot redhat dot com
OtherBugsDependingO 1233
             nThis:


http://sources.redhat.com/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

------- Additional Comments From eggert at gnu dot org  2005-08-24 22:21 -------
Created an attachment (id=613)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=613&action=view)
fix POSIX name space violations in regex.h


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

------- Additional Comments From eggert at gnu dot org  2005-08-24 22:23 -------
*** Bug 1233 has been marked as a duplicate of this bug. ***

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

------- Additional Comments From eggert at gnu dot org  2005-08-24 23:08 -------
Created an attachment (id=614)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=614&action=view)
add re_fastmap_accurate when _REGEX_SOURCE is defined

The original patch omitted a definition for re_fastmap_accurate,
which I found in subsequent testing.  This matters only for code
that is using the new (POSIX-compliant) names, so this bug does
not affect existing code.  I am attaching the obvious followup patch.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |1237
              nThis|                            |


http://sources.redhat.com/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-09-06 20:03 -------
There is no reason to rename REG_NOERROR etc.  The definitions are correct. 
There is also no requirement to have them as macros.

And stop making gratuitous changes like

-#define RE_DUP_MAX (0x7fff)
+/* Maximum number of duplicates an interval can allow.  This is
+   distinct from RE_DUP_MAX, to conform to POSIX name space rules and
+   to avoid collisions with <limits.h>.  */
+#define REG_DUP_MAX 32767

Broken code which tries to use the macro in preprocessor arithmetic cannot
mysteriously start working.

Likewise

-#define REG_ICASE (REG_EXTENDED << 1)
+#define REG_ICASE (1 << 1)

Nobody asked you for your opinion on how to write that code.  What you think is
irrelevant.  Leave the code alone.

+/* In the traditional GNU implementation, regex.h defined member names
+   like `buffer' that POSIX does not allow.  These members now have
+   names with leading `re_' (e.g., `re_buffer').  Support the old
+   names only if _REGEX_SOURCE is defined.  New programs should use
+   the new names.  */

While true that this violates the name space, no other names are reserved
either.  It makes no sense to changed this until the specification is changed.

+  unsigned char *_REG_RE_NAME (buffer);
 
-	/* Number of bytes to which `buffer' points.  */
-  unsigned long int allocated;
+	/* Number of bytes to which `re_buffer' points.  */

The new comments are more confusing.  Just leave them as they are.  People
reading the header only see _REG_RE_NAME(buffer) which mentions 'buffer' but no
're_buffer'.


+#define REG_UNALLOCATED 0
+#define REG_REALLOCATE 1
+#define REG_FIXED 2

No.  Add a REG_ prefix if anything has to be done.  REG_REGS_UNALLOCATED.



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

------- Additional Comments From eggert at gnu dot org  2006-04-11 06:58 -------
Created an attachment (id=965)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=965&action=view)
more-conservative patch to fix POSIX name space violations


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #613 is|0                           |1
           obsolete|                            |
 Attachment #614 is|0                           |1
           obsolete|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

------- Additional Comments From eggert at gnu dot org  2006-04-11 06:58 -------
I will attach a revised patch, now used in gnulib, which is much more
conservative.  The revised patch leaves almost all the names alone in
the normal case, and this addresses most of the objections.  If the
user compiles pedantically (e.g. by defining _POSIX_C_SOURCE), the
patched regex.h simply does not define the offending names; that
suffices to conform.

I didn't quite follow this objection, though:

> While true that this violates the name space, no other names are reserved
> either.

I take this to claim that names beginning with "re_" are not reserved.

However, XSI section 2.2.2 page 16 line 613
<http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_02.html>
says that <regex.h> implementations can define symbols with the
prefixes re_ and rm_, in the same sense that <errno.h> can define
symbols with the prefixes E[0-9A-Z].  Users therefore can't define
re_* and rm_* macros before including <regex.h>, just as they can't
define an E[0-9A-Z] macro before including <errno.h>.  So, in that
sense, the re_* and rm_* names are free for use within <regex.h>.
This may help to explain why Solaris 10 <regex.h> regex_t can have
members like "re_sc" and "re_len"; this is an allowed extension to the
standard.

PS.  For the record, the glibc <regex.h> identifiers that violate the
POSIX name space include macro names like
RE_BACKSLASH_ESCAPE_IN_LISTS, RE_SYNTAX_AWK, RE_DUP_MAX,
RE_TRANSLATE_TYPE, REGS_FIXED, and RE_NREGS; and member names like
buffer, allocated, start, and end.

For example, here is a program that strictly conforms to POSIX, and
works on Solaris 10, but doesn't work with glibc:

   #define _POSIX_C_SOURCE 200112L
   #define buffer 0
   #define start 0
   #include <regex.h>
   int RE_BACKSLASH_ESCAPE_IN_LISTS;
   int RE_SYNTAX_AWK;
   int RE_DUP_MAX;
   int RE_TRANSLATE_TYPE;
   int REGS_FIXED;
   int RE_NREGS;
   int main (void) { return 0; }


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[eggert at gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|1233, 1237                  |
              nThis|                            |
             Status|WAITING                     |NEW
            Version|2.3.5                       |2.4


http://sourceware.org/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug regex/1236] regex.h violates POSIX name space rules in several places

[schwab at linux-m68k dot org]

------- Additional Comments From schwab at linux-m68k dot org  2010-09-02 14:42 -------
Fixed in 2.10.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=1236

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.