Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Kaveh R. Ghazi]

 > From: Jim Wilson <wilson@cygnus.com>
 > 
 > This patch looks OK to me.  Go ahead and install it.
 > Jim

	Done.

--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Kaveh R. Ghazi]

 > From: "Philippe De Muyter" <phdm@macqel.be>
 > 
 > > Mon Apr 13 12:18:31 1998  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
 > >  
 > >         * frame.c: Include stdlib.h and unistd.h to possibly get various
 > >         function prototypes.  The fixproto script guarantees these header
 > >         files exist on the target system.
 > 
 > As I wrote before, stdlib.h and unistd.h are guaranteed to exist, but
 > there is no guarantee that you get a prototype for malloc from stdlib.h,
 > except if you define __USE_FIXED_PROTOTYPES__ before including stdlib.h.
 > 
 > Philippe De Muyter


	I considered doing that, but I wasn't completely sure defining
that macro unconditionally in libgcc2.c or frame.c was a good idea.  Are
we guaranteed that defining __USE_FIXED_PROTOTYPES__ is safe for all
platforms? (I don't know, I'm asking.) If it is safe, then why does the
wrapper exist at all? ... 

	I don't have strong feelings either way.  Whatever Jeff decides
is fine with me. 

		--Kaveh
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

> 	I considered doing that, but I wasn't completely sure defining
> that macro unconditionally in libgcc2.c or frame.c was a good idea.  Are
> we guaranteed that defining __USE_FIXED_PROTOTYPES__ is safe for all
> platforms? (I don't know, I'm asking.) If it is safe, then why does the
> wrapper exist at all? ... 

IIRC there are some functions for which the generated prototype is wrong on
some platforms (I do not remember which functions), but if you only want to get
the prototype for malloc then it is safe to define __USE_FIXED_PROTOTYPES__.

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jim Wilson]

	IIRC there are some functions for which the generated prototype is wrong on
	some platforms (I do not remember which functions), but if you only want to get
	the prototype for malloc then it is safe to define __USE_FIXED_PROTOTYPES__.

On SunOS4, and other BSD 4.[23] derived systems, the prototype for sprintf
and related functions are dangerously wrong.  The prototypes return int,
the actual (obsolete) library functions return char *.  This is in stdio.h
though.

Also, some gid_t/uid_t related functions are a problem, but I think those
were solved by not emitting full prototypes for them.  This is because these
types changed from int to short (or vice versa?).

In any case, it doesn't really matter.  We don't need to define
__USE_FIXED_PROTOTYPES__.  It is true that some systems will be missing
a malloc prototype, but we only need a prototype if char * and int are
different sizes, and we can be sure that all of those systems do have
a malloc prototype already.

Jim

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jeffrey A Law]

  In message < 199804162229.PAA20659@rtl.cygnus.com >you write:
  > Also, some gid_t/uid_t related functions are a problem, but I think those
  > were solved by not emitting full prototypes for them.  This is because these
  > types changed from int to short (or vice versa?).
Not that it's important, but it was "short" to "int". :-)

jeff

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

> In any case, it doesn't really matter.  We don't need to define
> __USE_FIXED_PROTOTYPES__.  It is true that some systems will be missing
> a malloc prototype, but we only need a prototype if char * and int are
> different sizes, and we can be sure that all of those systems do have
> a malloc prototype already.

We also need a prototype if the return convention for pointers and ints
are different (e.g. on some m68k systems : d0 for ints a0 for pointers)

Another reason for needing a prototype is when we take the address
of the function.

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jim Wilson]

	We also need a prototype if the return convention for pointers and ints
	are different (e.g. on some m68k systems : d0 for ints a0 for pointers)

Good point.  However, I think the same reasoning applies here.  Either these
systems must already have appropriate declarations in the system headers, or
else the compiler must already be using a safe ABI (e.g. some m68k systems
return pointers in both a0 and d0 just to be safe).  Otherwise, the compiler
that came with the system wouldn't work.

	Another reason for needing a prototype is when we take the address
	of the function.

Not clear what you mean.  A prototype is certainly desirable, but it is not
obvious that it is required.

If there is a problem, then we certainly should fix it, but I don't believe
that defining __USE_FIXED_PROTOTYPES__ is a good solution.

Jim

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

> 
> 	We also need a prototype if the return convention for pointers and ints
> 	are different (e.g. on some m68k systems : d0 for ints a0 for pointers)
> 
> Good point.  However, I think the same reasoning applies here.  Either these
> systems must already have appropriate declarations in the system headers, or
> else the compiler must already be using a safe ABI (e.g. some m68k systems
> return pointers in both a0 and d0 just to be safe).  Otherwise, the compiler
> that came with the system wouldn't work.

The declarations provided are not necessarily in stdlib.h (especially when
there is no stdlib.h :)), but can be in malloc.h e.g., or only in the
man pages.

> 
> 	Another reason for needing a prototype is when we take the address
> 	of the function.
> 
> Not clear what you mean.  A prototype is certainly desirable, but it is not
> obvious that it is required.

I meant 'a declaration' but that was a side note.  That happens in the support
library for ObjC : one module takes the address of malloc, free and friends
to initialize some structure fields.  If malloc and friends are not declared
before as being functions, the compilation fails.

> 
> If there is a problem, then we certainly should fix it, but I don't believe
> that defining __USE_FIXED_PROTOTYPES__ is a good solution.
> 
> Jim
> 

Perhaps could we put malloc and friends outside of __USE_FIXED_PROTOTYPES__
in the generated stdlib.h, even without a parameter list if a parameter list
seems risky ?

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

I wrote
> 
> IIRC there are some functions for which the generated prototype is wrong on
> some platforms (I do not remember which functions), but if you only want to get
> the prototype for malloc then it is safe to define __USE_FIXED_PROTOTYPES__.
> 

Alternatively, we could put malloc, realloc, calloc and free outside of
__USE_FIXED_PROTOTYPES__ in the generated stdlib.h.

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jim Wilson]

	Alternatively, we could put malloc, realloc, calloc and free outside of
	__USE_FIXED_PROTOTYPES__ in the generated stdlib.h.

I have been trying to discourage you from fixing this problem in stdlib.h
because I believe it is unsafe to put stuff there by default.

I just remembered another problem.  There exist many programs which have
their own declarations of these C library functions.  Some of them them
have wrong definitions.  Some of them have definitions which are not valid
POSIX, but which agree with the system's man pages.  There may also be 
declarations in the system header files in other files which are not POSIX.
If we add our own POSIX declarations to stdlib.h, we run the risk that some
programs won't compile with gcc anymore.  Dealing with all of these bug reports
will be a hassle, and I would rather not have them in the first place.

free incidentally is not entirely safe, because many older systems define
it as returning int, whereas ISO C says it returns void.

I can see that the Objective C runtime library is a problem.  However, it
looks like they already have a fix for it there.  objc/misc.c defines
__USE_FIXED_PROTOTYPES__ itself.  That at least limits the damage to the
Objective C runtime library.  If the target system has POSIX incompatibilities,
then the Objective C runtime may fail to work, but at least C programs will
still work.

Jim

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

> 
> 	Alternatively, we could put malloc, realloc, calloc and free outside of
> 	__USE_FIXED_PROTOTYPES__ in the generated stdlib.h.
> 
> I have been trying to discourage you from fixing this problem in stdlib.h
> because I believe it is unsafe to put stuff there by default.

I think that I understand your point of view, but that I was not clear enough.
On some systems, the native compiler does not provide a stdlib.h. The
behaviour of gcc on those systems is to provide a stdlib.h that is
basically empty, which is useless, unless we define __USE_FIXED_PROTOTYPES__.
On those systems only (and maybe only if enabled by some target macro),
I suggested to populate stdlib.h with some usefull prototypes or simply
extern declarations for functions known to be POSIX compliant.

> I just remembered another problem.  There exist many programs which have
> their own declarations of these C library functions.  Some of them them
> have wrong definitions.  Some of them have definitions which are not valid
> POSIX, but which agree with the system's man pages.  There may also be 
> declarations in the system header files in other files which are not POSIX.
> If we add our own POSIX declarations to stdlib.h, we run the risk that some
> programs won't compile with gcc anymore.  Dealing with all of these bug reports
> will be a hassle, and I would rather not have them in the first place.

I do not think that adding a stdlib.h file on a system where previously
there was none would make some program to not compile with gcc anymore.

Philippe

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jim Wilson]

OK.  I understand what you are proposing now.

This sounds like something we haven't tried before, and is less likely to
cause problems that stuff we have tried before, so I am willing to try it.

Jim

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 >   In message < 199804010732.XAA09115@cygnus.com >you write:
 >   > >  > 	Simple question.  Does gcc guarantee that after it diddles with
 >   > >  > the system headers that a stdlib.h exists in some form?
 >   > > I do not believe that is the case.
 >   > 
 >   > Gcc *does* guarantee that after it diddles with the system headers
 >   > that a stdlib.h exists in some form.
 >   > 
 >   > This is handled by fixproto, which is normally run after fixincludes.
 > 
 > I stand corrected.  Obviously, I'm not all that familiar with the
 > actions of fixproto :-)
 > 
 > jeff


	Okay, I looked in fixproto and it looks as if it makes sure that
both stdlib.h and unistd.h exist.  Therefore, I would like to submit the
following patch to clean up warnings in target files frame.c and
libgcc2.c. 

	It is especially useful in cases where sizeof(int) != sizeof(void*).
This matters when, e.g malloc, because there is no prototype, is
implicitly declared returning int but it is cast and assigned to a
pointer.  I get the following warnings on mips-sgi-irix6.2, among
several others, which are cured by the patch below:

 > ./libgcc2.c: In function `__bb_init_prg':
 > ./libgcc2.c:2096: warning: cast to pointer from integer of different size
 > ./libgcc2.c:2103: warning: cast to pointer from integer of different size
 > ./libgcc2.c:2107: warning: cast to pointer from integer of different size
 > ./libgcc2.c:2117: warning: cast to pointer from integer of different size
 > ./libgcc2.c:2144: warning: cast to pointer from integer of different size
 > ./libgcc2.c:2152: warning: cast to pointer from integer of different size
 > ./libgcc2.c: In function `__bb_trace_func':
 > ./libgcc2.c:2204: warning: cast to pointer from integer of different size
 > ./libgcc2.c: In function `__bb_trace_func_ret':
 > ./libgcc2.c:2267: warning: cast to pointer from integer of different size
 > ./libgcc2.c: In function `__bb_init_file':
 > ./libgcc2.c:2313: warning: cast to pointer from integer of different size
 > ./libgcc2.c: In function `__bb_init_trace_func':
 > ./libgcc2.c:2387: warning: cast to pointer from integer of different size


		--Kaveh







Mon Apr 13 12:18:31 1998  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
 
        * frame.c: Include stdlib.h and unistd.h to possibly get various
        function prototypes.  The fixproto script guarantees these header
        files exist on the target system.
        * libgcc2.c: Likewise.
 
        * gthr-single.h (__gthread_mutex_lock, __gthread_mutex_trylock,
        __gthread_mutex_unlock): Add __attribute__ ((__unused__)) to the
        function parameters.
        * libgcc2.c (__udiv_w_sdiv): Likewise.


diff -rup orig/egcs-980406/gcc/frame.c egcs-980406/gcc/frame.c
--- orig/egcs-980406/gcc/frame.c	Fri Apr  3 11:34:56 1998
+++ egcs-980406/gcc/frame.c	Sat Apr 11 15:12:27 1998
@@ -32,6 +32,11 @@ Boston, MA 02111-1307, USA.  */
    do not apply.  */
 
 #include "tconfig.h"
+
+/* fixproto guarantees these system headers exist. */
+#include <stdlib.h>
+#include <unistd.h>
+
 #include "defaults.h"
 
 #ifdef DWARF2_UNWIND_INFO
diff -rup orig/egcs-980406/gcc/gthr-single.h egcs-980406/gcc/gthr-single.h
--- orig/egcs-980406/gcc/gthr-single.h	Fri Apr  3 11:35:40 1998
+++ egcs-980406/gcc/gthr-single.h	Sat Apr 11 15:23:36 1998
@@ -42,19 +42,19 @@ __gthread_active_p ()
 }
 
 static inline int
-__gthread_mutex_lock (__gthread_mutex_t *mutex)
+__gthread_mutex_lock (__gthread_mutex_t *mutex __attribute__ ((__unused__)))
 {
   return 0;
 }
 
 static inline int
-__gthread_mutex_trylock (__gthread_mutex_t *mutex)
+__gthread_mutex_trylock (__gthread_mutex_t *mutex __attribute__ ((__unused__)))
 {
   return 0;
 }
 
 static inline int
-__gthread_mutex_unlock (__gthread_mutex_t *mutex)
+__gthread_mutex_unlock (__gthread_mutex_t *mutex __attribute__ ((__unused__)))
 {
   return 0;
 }
diff -rup orig/egcs-980406/gcc/libgcc2.c egcs-980406/gcc/libgcc2.c
--- orig/egcs-980406/gcc/libgcc2.c	Sat Apr  4 12:38:13 1998
+++ egcs-980406/gcc/libgcc2.c	Sat Apr 11 15:15:44 1998
@@ -31,6 +31,11 @@ Boston, MA 02111-1307, USA.  */
    do not apply.  */
 
 #include "tconfig.h"
+
+/* fixproto guarantees these system headers exist. */
+#include <stdlib.h>
+#include <unistd.h>
+
 #include "machmode.h"
 #include "defaults.h" 
 #ifndef L_trampoline
@@ -391,7 +396,10 @@ __udiv_w_sdiv (USItype *rp, USItype a1, 
 #else
 /* If sdiv_qrnnd doesn't exist, define dummy __udiv_w_sdiv.  */
 USItype
-__udiv_w_sdiv (USItype *rp, USItype a1, USItype a0, USItype d)
+__udiv_w_sdiv (USItype *rp __attribute__ ((__unused__)),
+	       USItype a1 __attribute__ ((__unused__)),
+	       USItype a0 __attribute__ ((__unused__)),
+	       USItype d __attribute__ ((__unused__)))
 {
   return 0;
 }

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

> Mon Apr 13 12:18:31 1998  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
>  
>         * frame.c: Include stdlib.h and unistd.h to possibly get various
>         function prototypes.  The fixproto script guarantees these header
>         files exist on the target system.

As I wrote before, stdlib.h and unistd.h are guaranteed to exist, but
there is no guarantee that you get a prototype for malloc from stdlib.h,
except if you define __USE_FIXED_PROTOTYPES__ before including stdlib.h.

Philippe De Muyter

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jim Wilson]

This patch looks OK to me.  Go ahead and install it.

Jim

egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Kaveh R. Ghazi]

	Simple question.  Does gcc guarantee that after it diddles with
the system headers that a stdlib.h exists in some form?

	For target files which include tconfig.h, since we can't check
autoconf macros, I'd like to hardwire including stdlib.h to possibly get
prototypes for malloc, et al. 

	This set of files would include frame.c and libgcc2.c.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		Icon CMT Corp.

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

> 	Simple question.  Does gcc guarantee that after it diddles with
> the system headers that a stdlib.h exists in some form?

I think the answer is `yes'...

> 	For target files which include tconfig.h, since we can't check
> autoconf macros, I'd like to hardwire including stdlib.h to possibly get
> prototypes for malloc, et al. 

... but the prototypes that did not exist before fixincludes etc are only
defined if either __USE_FIXED_PROTOTYPES__, __cplusplus or __STRICT_ANSI__
are defined.  In some objc file, I defined __USE_FIXED_PROTOTYPES__
before including stdlib.h to get the prototypes for malloc and friends.

Philippe

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Manfred Hollstein]

On Fri, 27 March 1998, 16:18:24, ghazi@caip.rutgers.edu wrote:

    	Simple question.  Does gcc guarantee that after it diddles with
    the system headers that a stdlib.h exists in some form?

Yes, it does. I have this situation on m68k-motorola-sysv. I've added
a small patch recently, which guarantees the generated stdlib.h
contains a definition for `size_t'. Otherwise, lots of g++ tests will fail.
    
    	For target files which include tconfig.h, since we can't check
    autoconf macros, I'd like to hardwire including stdlib.h to possibly get
    prototypes for malloc, et al. 

I'll have to look on Monday, which prototypes are actually generated.
    
    	This set of files would include frame.c and libgcc2.c.
    
    		Thanks,
    		--Kaveh

manfred

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Manfred Hollstein]

On Sat, 28 March 1998, 16:25:27, manfred@s-direktnet.de wrote:

 > On Fri, 27 March 1998, 16:18:24, ghazi@caip.rutgers.edu wrote:
 > 
 >     	Simple question.  Does gcc guarantee that after it diddles with
 >     the system headers that a stdlib.h exists in some form?
 > 
 > Yes, it does. I have this situation on m68k-motorola-sysv. I've added
 > a small patch recently, which guarantees the generated stdlib.h
 > contains a definition for `size_t'. Otherwise, lots of g++ tests will fail.
 >     
 >     	For target files which include tconfig.h, since we can't check
 >     autoconf macros, I'd like to hardwire including stdlib.h to possibly get
 >     prototypes for malloc, et al. 
 > 
 > I'll have to look on Monday, which prototypes are actually generated.

This is the generated one on the Motorola system:

#ifndef stdlib_h
#define stdlib_h

#define __need_size_t
#include <stddef.h>

#if defined(__USE_FIXED_PROTOTYPES__) || defined(__cplusplus) || defined (__STRICT_ANSI__)
extern void abort (void);
extern int abs (int);
extern int atexit (void (*) (void));
extern double atof (const char *);
extern int atoi (const char *);
extern long int atol (const char *);
extern void * bsearch (const void *, const void *, __SIZE_TYPE__ , __SIZE_TYPE__ , int (*) (const void *, const void *));
extern void * calloc (__SIZE_TYPE__ , __SIZE_TYPE__ );
extern void exit (int);
extern void free (void *);
extern char * getenv (const char *);
extern long int labs (long int);
extern void * malloc (__SIZE_TYPE__ );
extern int putenv (char *);
extern void qsort (void *, __SIZE_TYPE__ , __SIZE_TYPE__ , int (*) (const void *, const void *));
extern int rand (void);
extern void * realloc (void *, __SIZE_TYPE__ );
extern void srand (unsigned int);
extern double strtod (const char *, char **);
extern long int strtol (const char *, char **, int);
extern long unsigned int strtoul (const char *, char **, int);
extern int system (const char *);
#endif /* defined(__USE_FIXED_PROTOTYPES__) || ... */
#define EXIT_FAILURE 1
#define EXIT_SUCCESS 0
#endif /* stdlib_h */

manfred

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jeffrey A Law]

  In message < 199803272118.QAA25896@caip.rutgers.edu >you write:
  > 	Simple question.  Does gcc guarantee that after it diddles with
  > the system headers that a stdlib.h exists in some form?
I do not believe that is the case.

  > 	For target files which include tconfig.h, since we can't check
  > autoconf macros, I'd like to hardwire including stdlib.h to possibly get
  > prototypes for malloc, et al. 
  > 
  > 	This set of files would include frame.c and libgcc2.c.
We've still got ~1000 warnings in the compiler itself, let's nail
those before we go after the target stuff.

We've also got to get the cp, objc & f subdirs converted to system.h;
I've got "cp" done locally, I'll be checking it in after I give it
another looksie.

jeff

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Per Bothner]

>  > 	Simple question.  Does gcc guarantee that after it diddles with
>  > the system headers that a stdlib.h exists in some form?
> I do not believe that is the case.

Gcc *does* guarantee that after it diddles with the system headers
that a stdlib.h exists in some form.

This is handled by fixproto, which is normally run after fixincludes.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Jeffrey A Law]

  In message < 199804010732.XAA09115@cygnus.com >you write:
  > >  > 	Simple question.  Does gcc guarantee that after it diddles with
  > >  > the system headers that a stdlib.h exists in some form?
  > > I do not believe that is the case.
  > 
  > Gcc *does* guarantee that after it diddles with the system headers
  > that a stdlib.h exists in some form.
  > 
  > This is handled by fixproto, which is normally run after fixincludes.
I stand corrected.  Obviously, I'm not all that familiar with the
actions of fixproto :-)

jeff