small libf2c cleanups

small libf2c cleanups

[Richard Henderson]

Two of the changes are basicly covered by autoconf.  The signal_.c
change avoids casting a DImode pointer to SImode int on Alpha.  I
have no idea what the function is supposed to return, but what it
had been doing made no sense to me.


r~



Tue Oct 14 19:40:34 1997  Richard Henderson  <rth@cygnus.com>

	* libF77/signal_.c (G77_signal_0): Make return type sig_pf as well.
	* libI77/fio.h: Include <string.h> if STDC_HEADERS.
	* libU77/chmod_.c: Likewise.


Index: libF77/signal_.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/f/runtime/libF77/signal_.c,v
retrieving revision 1.1.1.1
diff -u -p -d -r1.1.1.1 signal_.c
--- signal_.c	1997/08/12 07:47:52	1.1.1.1
+++ signal_.c	1997/10/15 02:38:47
@@ -2,13 +2,13 @@
 #include "signal1.h"
 
 #ifdef KR_headers
-ftnint G77_signal_0 (sigp, proc) integer *sigp; sig_pf proc;
+sig_pf G77_signal_0 (sigp, proc) integer *sigp; sig_pf proc;
 #else
-ftnint G77_signal_0 (integer *sigp, sig_pf proc)
+sig_pf G77_signal_0 (integer *sigp, sig_pf proc)
 #endif
 {
 	int sig;
 	sig = (int)*sigp;
 
-	return (ftnint)signal(sig, proc);
+	return signal(sig, proc);
 	}
Index: libI77/fio.h
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/f/runtime/libI77/fio.h,v
retrieving revision 1.1.1.1
diff -u -p -d -r1.1.1.1 fio.h
--- fio.h	1997/08/12 07:47:53	1.1.1.1
+++ fio.h	1997/10/15 02:38:47
@@ -4,6 +4,9 @@
 /* ANSI C */
 #include <stddef.h>
 #endif
+#ifdef STDC_HEADERS
+#include <string.h>
+#endif
 
 #ifndef SEEK_SET
 #define SEEK_SET 0
Index: libU77/chmod_.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/f/runtime/libU77/chmod_.c,v
retrieving revision 1.2
diff -u -p -d -r1.2 chmod_.c
--- chmod_.c	1997/10/01 07:43:19	1.2
+++ chmod_.c	1997/10/15 02:38:48
@@ -31,6 +31,9 @@ Boston, MA 02111-1307, USA.  */
 #else
 #  include <stdio.h>
 #endif
+#if STDC_HEADERS
+#  include <string.h>
+#endif
 
 #include "f2c.h"
 

Re: small libf2c cleanups

[Jeffrey A Law]

  In message < 19971014194418.35064@dot.cygnus.com >you write:
  > Two of the changes are basicly covered by autoconf.  The signal_.c
  > change avoids casting a DImode pointer to SImode int on Alpha.  I
  > have no idea what the function is supposed to return, but what it
  > had been doing made no sense to me.
  > 
  > 
  > r~
  > 
  > 
  > 
  > Tue Oct 14 19:40:34 1997  Richard Henderson  <rth@cygnus.com>
  > 
  > 	* libF77/signal_.c (G77_signal_0): Make return type sig_pf as well.
  > 	* libI77/fio.h: Include <string.h> if STDC_HEADERS.
  > 	* libU77/chmod_.c: Likewise.
Installed.  We'll have to keep an eye on the signal stuff -- I'm not
100% sure of what we want to do with it either.

jeff

Re: small libf2c cleanups

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

 >> * libF77/signal_.c (G77_signal_0): Make return type sig_pf as well.

Note that changes to return types of the intrinsic implementations
should be reflected (at least) in com-rt.def.

 >> * libI77/fio.h: Include <string.h> if STDC_HEADERS.

Is this actually necessary?

 >> * libU77/chmod_.c: Likewise.

I wonder how it got like that...

 Jeffrey> Installed.  We'll have to keep an eye on the signal stuff --
 Jeffrey> I'm not 100% sure of what we want to do with it either.

I realize that the libf2c implemenation has changed underneath
configure and I either failed to notice or forgot to sort it out.
I'll investigate.

BTW I don't think burley is reading the list, primarily in view of his
mail normally being delivered to the GNU system...

Re: small libf2c cleanups

[Richard Henderson]

On Wed, Oct 15, 1997 at 10:23:20PM +0100, Dave Love wrote:
> >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
> 
>  >> * libF77/signal_.c (G77_signal_0): Make return type sig_pf as well.
> 
> Note that changes to return types of the intrinsic implementations
> should be reflected (at least) in com-rt.def.

I guess the question is: what information is intended to be returned?

Thing is, I don't know that there's really anything to change it to.
There's no pointer-sized-integer type is there?  

>  >> * libI77/fio.h: Include <string.h> if STDC_HEADERS.
> 
> Is this actually necessary?

One of the files, I forget which now, used one of the mem functions
without including <string.h>.  Will the library work without the 
include?  Yes.  But why?  You've already got the autoconf detection
macro already.

> 
>  >> * libU77/chmod_.c: Likewise.
> 
> I wonder how it got like that...
> 
>  Jeffrey> Installed.  We'll have to keep an eye on the signal stuff --
>  Jeffrey> I'm not 100% sure of what we want to do with it either.
> 
> I realize that the libf2c implemenation has changed underneath
> configure and I either failed to notice or forgot to sort it out.
> I'll investigate.
> 
> BTW I don't think burley is reading the list, primarily in view of his
> mail normally being delivered to the GNU system...

Re: small libf2c cleanups

[Dave Love]

>>>>> "Richard" == Richard Henderson <rth@dot.cygnus.com> writes:

 Richard> Thing is, I don't know that there's really anything to
 Richard> change it to.  There's no pointer-sized-integer type is
 Richard> there?

I've forgotten the details of the intrinsics and kind mechanisms and
how it last changed, but AFAIR it should be possible to do something
more sanitary now.

 >> >> * libI77/fio.h: Include <string.h> if STDC_HEADERS.
 >> 
 >> Is this actually necessary?

 Richard> One of the files, I forget which now, used one of the mem
 Richard> functions without including <string.h>.  Will the library
 Richard> work without the include?  Yes.  But why?  You've already
 Richard> got the autoconf detection macro already.

We have to keep libf2c in sync with the master version, so cosmetic
changes have mostly been avoided, but bug fixes are of interest for
g77 0.5.22 and f2c itself.  We should probably make a renewed attempt
to get some of the changes which have been made merged into the Netlib
version, though.

Re: small libf2c cleanups

[Jeffrey A Law]

  In message < 19971015233038.26757@dot.cygnus.com >you write:
  > On Wed, Oct 15, 1997 at 10:23:20PM +0100, Dave Love wrote:
  > I guess the question is: what information is intended to be returned?
  > 
  > Thing is, I don't know that there's really anything to change it to.
  > There's no pointer-sized-integer type is there?  
We could create one.


  > >  >> * libI77/fio.h: Include <string.h> if STDC_HEADERS.
  > > 
  > > Is this actually necessary?
  > 
  > One of the files, I forget which now, used one of the mem functions
  > without including <string.h>.  Will the library work without the 
  > include?  Yes.  But why?  You've already got the autoconf detection
  > macro already.
Also note that using them without a prototype can lead to problems
on some systems.  Like when size_t isn't the same size as an int
and you try to do something like strncpy (foo, bar, 5)


jeff

Re: small libf2c cleanups

[Jim Wilson]

	  > There's no pointer-sized-integer type is there?  
	We could create one.

We already have one, e.g.

typedef int ptr_type __attribute__ ((mode (pointer)));

Jim

Re: small libf2c cleanups

[Richard Henderson]

On Fri, Oct 17, 1997 at 11:29:08AM -0700, Jim Wilson wrote:
> 	  > There's no pointer-sized-integer type is there?  
> 	We could create one.
> 
> We already have one, e.g.
> 
> typedef int ptr_type __attribute__ ((mode (pointer)));

Actually it was Fortran, not C I was speaking of. 

I would be delighted if it's changed, but last I heard, g77 didn't
properly support integer*8.  So even if we declared the function
properly, you couldn't assign the value to anything without loosing
information.


r~

Re: small libf2c cleanups

[Toon Moene]

Richard Henderson wrote:

> On Fri, Oct 17, 1997 at 11:29:08AM -0700, Jim Wilson wrote:

> [ ... pointer sized int ... ]

>> We already have one, e.g.
>>
>> typedef int ptr_type __attribute__ ((mode (pointer)));

>  Actually it was Fortran, not C I was speaking of.
>
>  I would be delighted if it's changed, but last I heard,
>  g77 didn't properly support integer*8.  So even if we
>  declared the function properly, you couldn't assign the
>  value to anything without loosing information.

The Fortran, i.e. g77, counterpart of an integer large enough to  
hold a pointer is INTEGER(KIND=7).

However, I doubt that that is of any use in this discussion.

It really, really starts to be very irritating that Craig can't  
read the ongoing discussion in egcs@cygnus.com currently.

Cheers,
Toon.

Re: small libf2c cleanups

[Jeffrey A Law]

  In message < rzq201ll904.fsf@djlvig.dl.ac.uk >you write:
  >  Richard> One of the files, I forget which now, used one of the mem
  >  Richard> functions without including <string.h>.  Will the library
  >  Richard> work without the include?  Yes.  But why?  You've already
  >  Richard> got the autoconf detection macro already.
  > 
  > We have to keep libf2c in sync with the master version, so cosmetic
  > changes have mostly been avoided, but bug fixes are of interest for
  > g77 0.5.22 and f2c itself.  We should probably make a renewed attempt
  > to get some of the changes which have been made merged into the Netlib
  > version, though.
I would consider Richard's change a bugfix.  Who should I sent it to so
that it gets installed into the official version.

As to sync-ing with the netlib stuff, fine by me if someone sends patches.

jeff

Re: small libf2c cleanups

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 >> Thing is, I don't know that there's really anything to change it to.
 >> There's no pointer-sized-integer type is there?  
 Jeffrey> We could create one.

_Please_ don't change the language without consulting burley.
Especially in that nightmarish area!

 Jeffrey> Also note that using them without a prototype can lead to
 Jeffrey> problems on some systems.

Right, I just wanted to know if this was a real problem for the
released version that we should know about.

 Jeffrey> Like when size_t isn't the same size as an int and you try
 Jeffrey> to do something like strncpy (foo, bar, 5)

Sounds as though the GNU coding standard needs updating re. that
example.

Re: small libf2c cleanups

[Craig Burley]

>I would be delighted if it's changed, but last I heard, g77 didn't
>properly support integer*8.  So even if we declared the function
>properly, you couldn't assign the value to anything without loosing
>information.

Yes, it does, and if SIGNAL is supposed to return a pointer,
then g77 can handle that.

However, I can't figure out what SIGNAL is supposed to do in the
Fortran libU77 world (which I know little about, aside from what
I've learned by doing g77).  Presumably it is just a wrapper for
signal(2), in which case it looks like SIGNAL should return a pointer
as well.

It looks like the documentation for SIGNAL is botched a bit, at least,
in that it confuses the NUMBER and HANDLER arguments in the sentence
"If NUMBER is an integer...".  Can anyone confirm this?

Anyway, to teach g77 that an intrinsic returns a pointer as a
function value, change gcc/f/com-rt.def so its entry starts with
"Ip:", a la LOC.  However, I just noticed that fixing the subroutine
form of SIGNAL is non-trivial, since I didn't bother making "Ip" work
as an argument, probably because I was thinking only of LOC when
I implemented it.  Sigh.

Since I'm still muchly in flux in terms of my current systems, I can't
do much about this just yet, but maybe early this coming week I'll
be able to send patches for some of these things.

BTW, I've known SIGNAL probably didn't work right on Alphas for some
time, which is why gcc/f/BUGS contains an entry about it.  Thanks
for working on it!!

        tq vm, (burley)

Re: small libf2c cleanups

[Dave Love]

>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

 Craig> However, I can't figure out what SIGNAL is supposed to do in
 Craig> the Fortran libU77 world (which I know little about, aside
 Craig> from what I've learned by doing g77).  Presumably it is just a
 Craig> wrapper for signal(2), in which case it looks like SIGNAL
 Craig> should return a pointer as well.

The situation is a mess.  The f2c definition of signal disagrees with
the one in Sun Fortran, which we've teneded to regard as canonical.  I
don't know what the original BSD definition was but can probably find
out at work.  The Sun definition explcitly defines a function form
which returns an integer.  I doubt many people make use of it to
switch back and forth between handlers anyhow, and don't think it's
worth worrying about greatly.  The appropriate standard technique is
presumably posix.9 (on which someone was supposed to be working but
which we don't have).  I have in mind to implement as much of the
fortran2000 exception-handling proposal as sensible when it becomes
clear how configuring and building the compiler works eventually.

 Craig> It looks like the documentation for SIGNAL is botched a bit,
 Craig> at least, in that it confuses the NUMBER and HANDLER arguments
 Craig> in the sentence "If NUMBER is an integer...".  Can anyone
 Craig> confirm this?

Yes, I'll try to reconstruct it.

 Craig> Anyway, to teach g77 that an intrinsic returns a pointer as a
 Craig> function value, change gcc/f/com-rt.def so its entry starts
 Craig> with "Ip:", a la LOC.

... but this change would be incompatible.

 Craig> I can't do much about this just yet, but maybe early this
 Craig> coming week I'll be able to send patches for some of these
 Craig> things.

I was going to look at it, but the relevant disc seems to have gone
away.  Let me know whether or not I should do it later.

BTW, Fortran users definitley shouldn't be given the impression that
they can generally pass around C-like pointers without losing.

Re: small libf2c cleanups

[Jeffrey A Law]

  In message < rzqlnzp3ov1.fsf@djlvig.dl.ac.uk >you write:
  >  Craig> Anyway, to teach g77 that an intrinsic returns a pointer as a
  >  Craig> function value, change gcc/f/com-rt.def so its entry starts
  >  Craig> with "Ip:", a la LOC.
  > 
  > ... but this change would be incompatible.
Sorry, but I don't follow all this...  Just not familiar enough with g77.

Any thoughts on backing out the signal_.c patch until y'all come up with
a suitable solution for the intrinsics?

jeff

Re: small libf2c cleanups

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeffrey> Any thoughts on backing out the signal_.c patch until y'all
 Jeffrey> come up with a suitable solution for the intrinsics?

Well, it's definitely bogus without corresponding changes to
com-rt.def and f2cext.c.

Re: small libf2c cleanups

[Craig Burley]

>Any thoughts on backing out the signal_.c patch until y'all come up with
>a suitable solution for the intrinsics?

Either way; we're working on figuring this one out (well, Dave is,
I'm still fighting my equipment, at least I got kermit working --
again -- today, so I've been able to read email again ;-).

        tq vm, (burley)