Re: Minor change to regex.c

Re: Minor change to regex.c

[DJ Delorie]

> I'm pretty sure that ALMOST_STDC is just a historical relic and I
> didn't want to propagate it anywhere else.  If I'm wrong, let me know
> and I'll add it.

It was last used for MPW, so it's only slightly historical.  I'd
rather leave it for now just in case.  Preserving a little history now
is better than breaking an obscure platform later.

Re: Minor change to regex.c

[Kaveh R. Ghazi]

 > From: DJ Delorie <dj@redhat.com>
 > 
 > If you're using symcat.h as a guide, why not use the same logic symcat
 > uses?

Well, the difference is that symcat.h adds "|| defined (ALMOST_STDC)".

I'm pretty sure that ALMOST_STDC is just a historical relic and I
didn't want to propagate it anywhere else.  If I'm wrong, let me know
and I'll add it.  Or conversely I could make them identical by
removing ALMOST_STDC from symcat.h. :-)

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Minor change to regex.c

[DJ Delorie]

> I don't know what DJ did to import the code in libiberty but it must
> have included adding non-ISO C support.  So this patch should be
> added to his personal set.

I have done nothing yet, that's the problem.  The regex in libiberty
is exactly the same as the one in glibc, and I'd like to avoid having
local patches because they make importing new versions harder.  I
*can* maintain a local patch, but I'd rather not.  But we need to do
something to make it support K&R compilers, which is what we're
working on now.

Minor change to regex.c

[law]

It wasn't immediately clear from the glibc project web pages where to
send glibc patches.  So I'm sending two minor patches to you directly.

--

As you are probably aware, regex.c from glibc has been imported into
libiberty and is used by a number of projects.

Some of those projects (gcc and binutils in particular) require that their
source be compilable by non-ANSI/ISO compilers.

regex.c uses ANSI/ISO concatentation which, of course, breaks those lame
compilers.

This patch fixes the problem.

	* regex.c (PREFIX): Provide an alternate definition for
	non-ANSI/ISO compilers.
	(ARG_PREFIX): Likewise.

Index: regex.c
===================================================================
RCS file: /cvs/cvsfiles/devo/libiberty/regex.c,v
retrieving revision 1.6
diff -c -3 -p -r1.6 regex.c
*** regex.c	2001/11/13 03:52:48	1.6
--- regex.c	2001/11/15 18:00:24
*************** typedef enum
*** 612,618 ****
  # define UCHAR_T unsigned char
  # define COMPILED_BUFFER_VAR bufp->buffer
  # define OFFSET_ADDRESS_SIZE 2
! # define PREFIX(name) byte_##name
  # define ARG_PREFIX(name) name
  # define PUT_CHAR(c) putchar (c)
  #else
--- 612,622 ----
  # define UCHAR_T unsigned char
  # define COMPILED_BUFFER_VAR bufp->buffer
  # define OFFSET_ADDRESS_SIZE 2
! # if defined __STDC__ && __STDC__
! #  define PREFIX(name) byte_##name
! # else
! #  define PREFIX(name) byte_/**/name
! # endif
  # define ARG_PREFIX(name) name
  # define PUT_CHAR(c) putchar (c)
  #else
*************** typedef enum
*** 622,629 ****
  #  define COMPILED_BUFFER_VAR wc_buffer
  #  define OFFSET_ADDRESS_SIZE 1 /* the size which STORE_NUMBER macro use */
  #  define CHAR_CLASS_SIZE ((__alignof__(wctype_t)+sizeof(wctype_t))/sizeof(CH
AR_T)+1)
! #  define PREFIX(name) wcs_##name
! #  define ARG_PREFIX(name) c##name
  /* Should we use wide stream??  */
  #  define PUT_CHAR(c) printf ("%C", c);
  #  define TRUE 1
--- 626,638 ----
  #  define COMPILED_BUFFER_VAR wc_buffer
  #  define OFFSET_ADDRESS_SIZE 1 /* the size which STORE_NUMBER macro use */
  #  define CHAR_CLASS_SIZE ((__alignof__(wctype_t)+sizeof(wctype_t))/sizeof(CH
AR_T)+1)
! #  if defined __STDC__ && __STDC__
! #   define PREFIX(name) wcs_##name
! #   define ARG_PREFIX(name) c##name
! #  else
! #   define PREFIX(name) wcs_/**/name
! #   define ARG_PREFIX(name) c/**/name
! #  endif
  /* Should we use wide stream??  */
  #  define PUT_CHAR(c) printf ("%C", c);
  #  define TRUE 1



	

Re: Minor change to regex.c

[Ulrich Drepper]

DJ Delorie <dj@redhat.com> writes:

> You mean, besides the copyright notice which states "This file is part
> of the GNU C Library" like all the other files that you claim glibc is
> the master for?

You or somebody else added this, not me.

> Well, then, where *is* the master?  And do you send all your patches
> back to the master so that it is kept up to date?

I'm not sending the patches for regex anywhere because for this file I
don't strive for portability.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: Minor change to regex.c

[DJ Delorie]

> And let them accumulate bit rot there?  That's crap.  In glibc the K&R
> stuff would never ever be tested

No, of course not.  How naive do you think we are?  My goal is to keep
libiberty and glibc in sync, so the non-ISO bits will be constantly
tested as part of the gcc bootstrap process.

> > Otherwise, what's the point of glibc being the master source for
> > that file?
> 
> Who said that?  If the master repository is in glibc this is noted in
> the file.

You mean, besides the copyright notice which states "This file is part
of the GNU C Library" like all the other files that you claim glibc is
the master for?

> This is not the case for regex.

Well, then, where *is* the master?  And do you send all your patches
back to the master so that it is kept up to date?

Re: Minor change to regex.c

[Ulrich Drepper]

law@redhat.com writes:

> As you are probably aware, regex.c from glibc has been imported into
> libiberty and is used by a number of projects.

There are other, much more complicated cases where ISO C is required.
In fact, the glibc version of the file cannot be used with no-ISO C
compilers without quite a lot of changes.  This means, ISO C is not
supported.  I don't know what DJ did to import the code in libiberty
but it must have included adding non-ISO C support.  So this patch
should be added to his personal set.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: Minor change to regex.c

[Ulrich Drepper]

law@redhat.com writes:

> FWIW, with the patches I sent today, I can now build with the bundled
> (non-ANSI) C compiler from hpux10.20, which has been one of the most
> notoriously lame compilers over the years.

So this compiler can handle string concatenation which isn't K&R.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: Minor change to regex.c

[law]

  > 
  > > I don't know what DJ did to import the code in libiberty but it must
  > > have included adding non-ISO C support.  So this patch should be
  > > added to his personal set.
  > 
  > I have done nothing yet, that's the problem.  The regex in libiberty
  > is exactly the same as the one in glibc, and I'd like to avoid having
  > local patches because they make importing new versions harder.  I
  > *can* maintain a local patch, but I'd rather not.  But we need to do
  > something to make it support K&R compilers, which is what we're
  > working on now.
FWIW, with the patches I sent today, I can now build with the bundled
(non-ANSI) C compiler from hpux10.20, which has been one of the most
notoriously lame compilers over the years.

jeff

Re: Minor change to regex.c

[law]

> cc -c -DHAVE_CONFIG_H -g -I. -I../../gcc/libiberty/../include   ../../gcc/lib
> iberty/regex.c
> "../../gcc/libiberty/regex.c", line 1550: undefined or not a type: fail_stack
> _elt
> "../../gcc/libiberty/regex.c", line 1551: cannot recover from previous errors
> cc: acomp failed for ../../gcc/libiberty/regex.c
> make: *** [regex.o] Error 2
> 
> I got this on sun solaris 2.7 with 'WorkShop Compilers 5.0 98/12/15 C 5.0'.
> This happens because __STDC__ is defined 0. FYI
> 
> # if defined __STDC__  && __STDC__
> #  define PREFIX(name) byte_##name
> # else
> # else
> #  define PREFIX(name) byte_/**/name
> # endif
And your proposed fix would be?

jeff

Re: Minor change to regex.c

[law]

> This patch fixed the problem for me on Solaris2.7.  The macro checks
> are similar to what has long worked in libiberty's symcat.h.
> 
> Okay to install?
> 
> 
> 
> 2001-11-15  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
> 
> 	* regex.c: Check defined(__STDC__) || defined(HAVE_STRINGIZE)
> 	to determine whether cpp ISO C token pasting is available.
OK.  Thanks for taking care of this.

jeff

Re: Minor change to regex.c

[DJ Delorie]

> DJ Delorie <dj@redhat.com> writes:
> > But we need to do something to make it support K&R compilers, which
> > is what we're working on now.
> 
> I'm not going to maintain K&R changes.  So you better do it yourself.

We're not asking you to actively maintain them, just to let us
maintain them in the glibc cvs repository.  Otherwise, what's the
point of glibc being the master source for that file?  Or, if you
don't want glibc to be the master, then where *is* the master that you
send your patches to?

Re: Minor change to regex.c

[DJ Delorie]

> Would it be proper solution to include symcat.h and just use CONCAT for PREFIX?

For files shared with other GNU projects, we should seek to minimize
changes from the master versions.  Forcing other projects to copy
symcat.h just to use regex is inappropriate.

Re: Minor change to regex.c

[Ulrich Drepper]

DJ Delorie <dj@redhat.com> writes:

> I copied that line from the glibc cvs repository.

Maybe from another file but not for regex.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: Minor change to regex.c

[Ulrich Drepper]

DJ Delorie <dj@redhat.com> writes:

> We're not asking you to actively maintain them, just to let us
> maintain them in the glibc cvs repository.

And let them accumulate bit rot there?  That's crap.  In glibc the K&R
stuff would never ever be tested and if necessary there will be more
and more non-ISO C changes.

> Otherwise, what's the point of glibc being the master source for
> that file?

Who said that?  If the master repository is in glibc this is noted in
the file.  This is not the case for regex.

> Or, if you don't want glibc to be the master, then where *is* the
> master that you send your patches to?

I'm maintaining the glibc version.  What everybody else does is none
of my business.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: Minor change to regex.c

[Andrey Petrov]

On Thu, Nov 15, 2001 at 09:30:25PM -0500, DJ Delorie wrote:
> 
> If you're using symcat.h as a guide, why not use the same logic symcat
> uses?

Would it be proper solution to include symcat.h and just use CONCAT for PREFIX?

	Andrey

Re: Minor change to regex.c

[DJ Delorie]

> > You mean, besides the copyright notice which states "This file is part
> > of the GNU C Library" like all the other files that you claim glibc is
> > the master for?
> 
> You or somebody else added this, not me.

I copied that line from the glibc cvs repository.

Re: Minor change to regex.c

[Kaveh R. Ghazi]

 > From: Andrey Petrov <and@genesyslab.com> 
 > 
 > cc -c -DHAVE_CONFIG_H -g -I. -I../../gcc/libiberty/../include ../../gcc/libiberty/regex.c
 > "../../gcc/libiberty/regex.c", line 1550: undefined or not a type: fail_stack_elt
 > "../../gcc/libiberty/regex.c", line 1551: cannot recover from previous
 > errors
 > cc: acomp failed for ../../gcc/libiberty/regex.c
 > make: *** [regex.o] Error 2
 > 
 > I got this on sun solaris 2.7 with 'WorkShop Compilers 5.0 98/12/15 C
 > 5.0'.  This happens because __STDC__ is defined 0. FYI
 > 
 > # if defined __STDC__  && __STDC__
 > #  define PREFIX(name) byte_##name
 > # else
 > # else
 > #  define PREFIX(name) byte_/**/name
 > # endif

This patch fixed the problem for me on Solaris2.7.  The macro checks
are similar to what has long worked in libiberty's symcat.h.

Okay to install?



2001-11-15  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* regex.c: Check defined(__STDC__) || defined(HAVE_STRINGIZE)
	to determine whether cpp ISO C token pasting is available.
	
diff -rup /tmp/egcs-CVS20011115/libiberty/regex.c egcs-CVS20011115/libiberty/regex.c
--- /tmp/egcs-CVS20011115/libiberty/regex.c	Thu Nov 15 16:31:14 2001
+++ egcs-CVS20011115/libiberty/regex.c	Thu Nov 15 21:04:13 2001
@@ -612,7 +612,7 @@ typedef enum
 # define UCHAR_T unsigned char
 # define COMPILED_BUFFER_VAR bufp->buffer
 # define OFFSET_ADDRESS_SIZE 2
-# if defined __STDC__ && __STDC__
+# if defined (__STDC__) || defined (HAVE_STRINGIZE)
 #  define PREFIX(name) byte_##name
 # else
 #  define PREFIX(name) byte_/**/name
@@ -626,7 +626,7 @@ typedef enum
 #  define COMPILED_BUFFER_VAR wc_buffer
 #  define OFFSET_ADDRESS_SIZE 1 /* the size which STORE_NUMBER macro use */
 #  define CHAR_CLASS_SIZE ((__alignof__(wctype_t)+sizeof(wctype_t))/sizeof(CHAR_T)+1)
-#  if defined __STDC__ && __STDC__
+#  if defined (__STDC__) || defined (HAVE_STRINGIZE)
 #   define PREFIX(name) wcs_##name
 #   define ARG_PREFIX(name) c##name
 #  else

Re: Minor change to regex.c

[Andrey Petrov]

cc -c -DHAVE_CONFIG_H -g -I. -I../../gcc/libiberty/../include   ../../gcc/libiberty/regex.c
"../../gcc/libiberty/regex.c", line 1550: undefined or not a type: fail_stack_elt
"../../gcc/libiberty/regex.c", line 1551: cannot recover from previous errors
cc: acomp failed for ../../gcc/libiberty/regex.c
make: *** [regex.o] Error 2

I got this on sun solaris 2.7 with 'WorkShop Compilers 5.0 98/12/15 C 5.0'.
This happens because __STDC__ is defined 0. FYI

# if defined __STDC__  && __STDC__
#  define PREFIX(name) byte_##name
# else
# else
#  define PREFIX(name) byte_/**/name
# endif



Regards,
	Andrey

Re: Minor change to regex.c

[Ulrich Drepper]

DJ Delorie <dj@redhat.com> writes:

> But we need to do something to make it support K&R compilers, which
> is what we're working on now.

I'm not going to maintain K&R changes.  So you better do it yourself.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: Minor change to regex.c

[DJ Delorie]

If you're using symcat.h as a guide, why not use the same logic symcat
uses?

Re: Minor change to regex.c

[Kaveh R. Ghazi]

 > From: DJ Delorie <dj@redhat.com>
 > 
 > > I'm pretty sure that ALMOST_STDC is just a historical relic and I
 > > didn't want to propagate it anywhere else.  If I'm wrong, let me know
 > > and I'll add it.
 > 
 > It was last used for MPW, so it's only slightly historical.  I'd
 > rather leave it for now just in case.  Preserving a little history now
 > is better than breaking an obscure platform later.

Done.

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions