Re: K&R and ISO

Re: K&R and ISO

[Roland McGrath]

> I already did, when I brought the point to U.D., regex.[ch] is use in
> many packages and will not compile without an ANSI C.  I'm a bit worry that
> next time I'll look, it will need not only an ANSI C comp. but gcc.

There has been no suggestion to reduce the level of support for ANSI C
compilers other than GCC, and I don't think that retaining portability to
all ANSI C compliant compilers will be a problem in the future.  I think
that the libc team will happily continue to accept reports of
nonportability to ANSI C compilers for these shared files as bonafide bugs.

The remaining question is, is portability to non-ANSI C compilers is
important to you at all, and if so, can you just you ansi2knr or protoize
and be happy?

Re: K&R and ISO

[Alain Magloire]

> 
> > I already did, when I brought the point to U.D., regex.[ch] is use in
> > many packages and will not compile without an ANSI C.  I'm a bit worry that
> > next time I'll look, it will need not only an ANSI C comp. but gcc.
> 
> There has been no suggestion to reduce the level of support for ANSI C
> compilers other than GCC, and I don't think that retaining portability to
> all ANSI C compliant compilers will be a problem in the future.  I think
> that the libc team will happily continue to accept reports of
> nonportability to ANSI C compilers for these shared files as bonafide bugs.

Thank you, for the clarification.

> 
> The remaining question is, is portability to non-ANSI C compilers is
> important to you at all,

Yes, it is.

> and if so, can you just you ansi2knr or protoize
> and be happy?

No. Certain semantics, will not pass like concatenation of strings
at compile time.

	printf ("hello " "world\n");

The same for line split: I think ANSI C demands that one use a \
but some compilers will complain some will not, if you don't put it.

	printf ("hello  
world\n");

Obviously, I can not talk for all maintainers, but we do reuse code
from glibc regex, glob, etc .. to name a few.  Improvements in code such
as regex is valuable for many *utils tools.  If glibc decides
to provide supports for only ANSI C, then it is time to bid farewell
and exchange goodby kisses.

My life will just be a tad more complex.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!

Re: K&R and ISO

[Roland McGrath]

> > and if so, can you just you ansi2knr or protoize
> > and be happy?
> 
> No. Certain semantics, will not pass like concatenation of strings
> at compile time.
> 
> 	printf ("hello " "world\n");
> 
> The same for line split: I think ANSI C demands that one use a \
> but some compilers will complain some will not, if you don't put it.
> 
> 	printf ("hello  
> world\n");

Hmm.  Ok.  I do not speak for the libc maintainers, but still I don't think
it will be a burden to avoid these few particular features for a few files
(I assume they are not used now in any files that you care about).  If
ansi2knr/protoize can be made to flag these features and complain at you,
then your normal testing of new libc code can readily flag these problems
before they get into your packages.  If you report these and supply the
necessary fixes, I don't think the libc maintainers would have any trouble
folding in those changes for the benefit of packages like yours.

Re: K&R and ISO

[Alain Magloire]

> 
> > > and if so, can you just you ansi2knr or protoize
> > > and be happy?
> > 
> > No. Certain semantics, will not pass like concatenation of strings
> > at compile time.
> > 
> > 	printf ("hello " "world\n");
> > 
> > The same for line split: I think ANSI C demands that one use a \
> > but some compilers will complain some will not, if you don't put it.
> > 
> > 	printf ("hello  
> > world\n");
> 
> Hmm.  Ok.  I do not speak for the libc maintainers, but still I don't think
> it will be a burden to avoid these few particular features for a few files
> (I assume they are not used now in any files that you care about).  If
> ansi2knr/protoize can be made to flag these features and complain at you,
> then your normal testing of new libc code can readily flag these problems
> before they get into your packages.  If you report these and supply the
> necessary fixes, I don't think the libc maintainers would have any trouble
> folding in those changes for the benefit of packages like yours.

The above was done, when I raised the flag, the answer was a flat "no".
However, I did not submit a patch, doing this would revert to the old
ways of having error msg, which exactly what the new code was trying
to avoid.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!

Re: K&R and ISO

[Ulrich Drepper]

"Alain Magloire" <alain@qnx.com> writes:

> The above was done, when I raised the flag, the answer was a flat "no".

I will not revert the patches to regex.c since they are optimizations
which buy quite a lot in the glibc context.  If there is a way to keep
it usable without obsfutating the sources that's fine.  Somebody
should come up with a patch.  I personally don't care a thing for K&R
compilers.  All you need is make, gcc, and perhaps binutils.  With
this you can get gcc running and you are set.  If somebody does not
want to do this because it's too much work they cannot expect the
maintainer to spend time on their problems.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: K&R and ISO

[Alain Magloire]

Bonjour

> "Alain Magloire" <alain@qnx.com> writes:
> 
> > The above was done, when I raised the flag, the answer was a flat "no".
> 
> I will not revert the patches to regex.c since they are optimizations
> which buy quite a lot in the glibc context. 

> If there is a way to keep
> it usable without obsfutating the sources that's fine.  Somebody
> should come up with a patch.

No, this is a loosing strategy, it does not scale.  If you choose to walk this
path and use the full ANSI C semantics then be it.

> I personally don't care a thing for K&R
> compilers.  All you need is make, gcc, and perhaps binutils.  With
> this you can get gcc running and you are set.  If somebody does not
> want to do this because it's too much work they cannot expect the
> maintainer to spend time on their problems.

K&R is dead! The king is dead! Long Live the King!

Epitaphe for K&R :

... Surrender I?
Parley?  No, never!  You too, Folly, --you?
I know that you will lay me low at last;
Let be!  Yet I fall fighting, fighting still!
You strip from me the laurel and the rose!
Take all!  Despite you there is yet one thing
I hold against you all, and when, tonight,
I enter Christ's fair courts, and, lowly bowed,
Sweep with doffed casque the heaven's threshold blue,
One thing is left, that, void of stain or smutch,
I bear away despite you.
... My panache.
             [Cyrano De Bergerac, --Rostand]

Sortie, rideau, Ovation de la foule.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!

Re: K&R and ISO

[Andreas Jaeger]

>>>>> Ulrich Drepper writes:

 > Roland McGrath <roland@frob.com> writes:
>> I'd just like to give the maintainers a chance to explicitly respond
>> to your proposal before just deciding for them.

 > I'll leave the two files glob.h and fnmatch.h alone until this is
 > resolved.

 > Anybody else want to comment.  So far we have three votes for yes
 > (rth, roland, me).

As long as the headers still work with other compilers (ISO C89) than
gcc and the needs of other GNU packages are fulfilled, I vote for yes.

Andreas
-- 
 Andreas Jaeger   
  SuSE Labs aj@suse.de	
   private aj@arthur.rhein-neckar.de

Re: K&R and ISO

[Mark Kettenis]

   From: Ulrich Drepper <drepper@cygnus.com>
   Date: 08 Oct 1999 10:55:21 -0700

   I'll leave the two files glob.h and fnmatch.h alone until this is
   resolved.

Other headers that are shared with other GNU packages are error.h,
getopt.h, malloc.h, obstack.h and regex.h.

As far as I can tell error.h, getopt.h and obstack.h don't use too
much preprocessor madness to deal with K&R C.  Wolfgang probably has
something to say about malloc.h and maybe some other GNU developers
besides Alain (Jim Meyering?) have some wishes about regex.h.  Please
give them some time (more than a few days) to react before you touch
those files (if you plan to touch them at all).

   Anybody else want to comment.  So far we have three votes for yes
   (rth, roland, me).

I have no strong opinions.  Several Hurd specific include files
already use plain ISO C.  However be prepared to get flamed about this
issue.  The whole ``glibc developers force people to use gcc''
flamewar will start all over again :-(.

Mark

Re: K&R and ISO

[Ulrich Drepper]

"Alain Magloire" <alain@qnx.com> writes:

> I'm a bit worry that next time I'll look, it will need not only an
> ANSI C comp. but gcc.

This is not a problem.  ISO C is sufficently sane.  I only don't like
this K&R ballast.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: K&R and ISO

[Philip Blundell]

>Anybody else want to comment.  So far we have three votes for yes
>(rth, roland, me).

I also vote for yes.

p.

Re: K&R and ISO

[Zack Weinberg]

Ulrich Drepper wrote:
> Roland McGrath <roland@frob.com> writes:
> 
> > I'd just like to give the maintainers a chance to explicitly respond
> > to your proposal before just deciding for them.
> 
> I'll leave the two files glob.h and fnmatch.h alone until this is
> resolved.
> 
> Anybody else want to comment.  So far we have three votes for yes
> (rth, roland, me).

I like the idea, but remember that people want to use libc headers
with compilers other than GCC.  Those compilers usually support C89
but don't understand the __ form of keywords.  So we should #define
them to the non-underscored form if __GNUC__ is not defined.  Also,
__restrict still needs to be conditional.

zw

Re: K&R and ISO

[Alain Magloire]

> 
> > I don't understand.  Gcc can happily mix K&R code and ISO code.  Using
> > the -traditional flag of gcc already does not work so this is no
> > additional restriction.
> 
> That is what I said.  We are in agreement.
> 
> > The only program needed for bootstrapping which takes code from glibc
> > is make.  For fnmatch/glob we can either leave them as is or use
> > ansi2knr or unprotoize.  The latter is what many GNU packages do
> > nowadays.
> 
> Though I guess it is not a priority for GNU, I would like to leave the
> decisions of how portable to what systems each package needs to be to the
> discretion of that package's maintainer.  If using ansi2knr or unprotoize
> is sufficient, then all the better.  I'd just like to give the maintainers
> a chance to explicitly respond to your proposal before just deciding for them.

I already did, when I brought the point to U.D., regex.[ch] is use in
many packages and will not compile without an ANSI C.  I'm a bit worry that
next time I'll look, it will need not only an ANSI C comp. but gcc.

Of course I can not impose my views on the course of glibc, and I certainly
can understand U.D. not to want to carry those extra wait any longer.
Maybe it's time for a scission, in any case I(and many other maintainers)
did benefice from the general improvements made in this forum.


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!

Re: K&R and ISO

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> I'd just like to give the maintainers a chance to explicitly respond
> to your proposal before just deciding for them.

I'll leave the two files glob.h and fnmatch.h alone until this is
resolved.

Anybody else want to comment.  So far we have three votes for yes
(rth, roland, me).

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: K&R and ISO

[Roland McGrath]

> I don't understand.  Gcc can happily mix K&R code and ISO code.  Using
> the -traditional flag of gcc already does not work so this is no
> additional restriction.

That is what I said.  We are in agreement.

> The only program needed for bootstrapping which takes code from glibc
> is make.  For fnmatch/glob we can either leave them as is or use
> ansi2knr or unprotoize.  The latter is what many GNU packages do
> nowadays.

Though I guess it is not a priority for GNU, I would like to leave the
decisions of how portable to what systems each package needs to be to the
discretion of that package's maintainer.  If using ansi2knr or unprotoize
is sufficient, then all the better.  I'd just like to give the maintainers
a chance to explicitly respond to your proposal before just deciding for them.

Re: K&R and ISO

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> I don't see a problem for libc itself, as long as you make sure that it
> still works to use gcc to compile K&R code with libc.  That is,
> unconditionally using prototype declarations shouldn't be a problem.

I don't understand.  Gcc can happily mix K&R code and ISO code.  Using
the -traditional flag of gcc already does not work so this is no
additional restriction.

> In the case of the new reserved words, we can just use __const et
> al as now and let gcc's lexer rather than the preprocessor deal with them;
> it already handles the __ified names for the new reserved words.

This is what I intended to do.  Simply remove the __const, __signed,
__volatile macro definitions.

> The problematic question is for the various pieces of libc that are also
> used in other packages.  You should ask gnu-prog about the needs there.
> I would be inclined to leave all those (glob, fnmatch, etc) as they are.

The only program needed for bootstrapping which takes code from glibc
is make.  For fnmatch/glob we can either leave them as is or use
ansi2knr or unprotoize.  The latter is what many GNU packages do
nowadays.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: K&R and ISO

[Roland McGrath]

I don't see a problem for libc itself, as long as you make sure that it
still works to use gcc to compile K&R code with libc.  That is,
unconditionally using prototype declarations shouldn't be a problem.  Using
const instead of __const, et al, might be a problem for some old programs;
and I don't think it is worthwhile to break those without gleaning a real
benefit.  In the case of the new reserved words, we can just use __const et
al as now and let gcc's lexer rather than the preprocessor deal with them;
it already handles the __ified names for the new reserved words.

The problematic question is for the various pieces of libc that are also
used in other packages.  You should ask gnu-prog about the needs there.
I would be inclined to leave all those (glob, fnmatch, etc) as they are.

K&R and ISO

[Ulrich Drepper]

Hi,

I got today the news that ISO C99 passed the JTC.  This has multiple
implications:

- glibc is (almost) ready

- we are missing the nice "ISO C9A" joke


But this also brought up anothing thing: after 10 years we are still
carrying around the balast of K&R.  And this with a cost everybody has
to pay everything s/he uses a compiler.

I really think this is not acceptable anymore.  K&R is dead, at least
on GNU platforms.  Therefore I would like to drop all K&R
compatibility.  This means, all headers will loose the __P and the
__const and whatever junk we have.  I think this can considerably
speed up the preprocessor.

Does anybody have problems with this?  Are there any chances that you
could thinnk this is a problem?

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------