X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id:	<200112251052.LAA10619@father.ludd.luth.se>
Subject:	Re: gcc 3.03 and libc sources
In-Reply-To:	<Pine.SUN.3.91.1011225095732.3951K-100000@is> from Eli Zaretskii at "Dec 25, 2001 09:58:11 am"
To:	djgpp-workers AT delorie DOT com
Date:	Tue, 25 Dec 2001 11:52:20 +0100 (MET)
X-Mailer:	ELM [version 2.4ME+ PL54 (25)]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Meanwhile I've been correcting some other nags from gcc (handpasted so
might not apply cleanly):

Index: djgpp//src/libc/compat/stdlib/fcvtbuf.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/compat/stdlib/fcvtbuf.c,v
retrieving revision 1.1
diff -p -u -r1.1 fcvtbuf.c
--- djgpp//src/libc/compat/stdlib/fcvtbuf.c     1998/07/25 18:58:44     1.1
+++ djgpp//src/libc/compat/stdlib/fcvtbuf.c     2001/12/25 10:42:42
@@ -2,6 +2,7 @@
 #include <stdlib.h>
 #include <stdio.h>
 #include <string.h>
+#include <unistd.h>
 #include <float.h>
 #include <locale.h>

@@ -27,7 +28,7 @@ fcvtbuf (double value, int ndigits, int

   /* Where's the decimal point?  */
   dot = strchr (s, decimal);
-  *decpt = dot ? dot - s : strlen (s);
+  *decpt = dot ? dot - s : (ssize_t)strlen (s);

   /* SunOS docs says if NDIGITS is 8 or more, produce "Infinity"
      instead of "Inf".  */
Index: djgpp//src/libc/compat/unistd/_irdlink.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/compat/unistd/_irdlink.c,v
retrieving revision 1.3
diff -p -u -r1.3 _irdlink.c
--- djgpp//src/libc/compat/unistd/_irdlink.c    2001/06/27 17:42:32     1.3
+++ djgpp//src/libc/compat/unistd/_irdlink.c    2001/12/25 10:42:42
@@ -115,7 +115,7 @@ int __internal_readlink(const char * __p

    data_buf = buf + _SYMLINK_PREFIX_LEN;
    bytes_read = strchr(data_buf, '\n') - data_buf;
-   bytes_read = ((unsigned)bytes_read > __max) ? __max : bytes_read;
+   bytes_read = ((unsigned)bytes_read > __max) ? (ssize_t)__max : bytes_read;
    memcpy(__buf, data_buf, bytes_read);
    return bytes_read;
 }
Index: djgpp//src/libc/dos/process/dosexec.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/dos/process/dosexec.c,v
retrieving revision 1.19
diff -p -u -r1.19 dosexec.c
--- djgpp//src/libc/dos/process/dosexec.c       2001/08/21 03:22:46     1.19
+++ djgpp//src/libc/dos/process/dosexec.c       2001/12/25 10:42:47
@@ -1007,7 +1007,7 @@ static int go32_exec(const char *program
   /* Starting from DJGPP v2.04, programs are always run through !proxy.
      This allows correctly handle symlinks to .exes. */
   if (!check_talloc(found_si ?
-                   type->stubinfo->struct_length : 0
+                   (unsigned int)(type->stubinfo->struct_length) : 0
                    + (argc+1)*sizeof(short)))
   {
     argv[0] = save_argv0;
Index: djgpp//src/libc/posix/sys/stat/lstat.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/posix/sys/stat/lstat.c,v
retrieving revision 1.8
diff -p -u -r1.8 lstat.c
--- djgpp//src/libc/posix/sys/stat/lstat.c      2001/12/01 20:22:37     1.8
+++ djgpp//src/libc/posix/sys/stat/lstat.c      2001/12/25 10:42:48
@@ -325,7 +325,7 @@ get_inode_from_sda(const char *mybasenam
   unsigned short our_mem_base   = _my_ds();
   char  * dot                   = strchr(mybasename, '.');
   size_t  total_len             = strlen(mybasename);
-  int     name_len              = dot ? dot - mybasename : total_len;
+  int     name_len              = dot ? dot - mybasename : (ssize_t)total_len;
   int     ext_len               = dot ? total_len - name_len - 1 : 0;
   int     cluster_offset        = offsetof(struct full_dirent, fcluster);


--------------------

Thus I have now a better understanding of the following:

According to Eli Zaretskii:
> 
> On Mon, 24 Dec 2001, Martin Str|mberg wrote:
> 
> > gcc ... -c doprnt.c
> > cc1.exe: warnings being treated as errors
> > doprnt.c: In function `_doprnt':
> > doprnt.c:303: warning: signed and unsigned type in conditional expression
> > doprnt.c:347: warning: signed and unsigned type in conditional expression
> > doprnt.c:354: warning: signed and unsigned type in conditional expression
> > #define ARG(basetype) _ulonglong = \
> >                 flags&LONGDBL ? va_arg(argp, long long basetype) : \
> >                 flags&LONGINT ? va_arg(argp, long basetype) : \
> >                 flags&SHORTINT ? (short basetype)va_arg(argp, int) : \
> >                 va_arg(argp, int)
> > [...]
> > I'm not sure what I should do to solve this.
> 
> Report a bug to the gcc-bug mailing list, I guess.  I don't see
> anything wrong with the code it flags here.
> 
> Note that the complaints are about the calls of ARG with an unsigned
> type as its argument, while `flags' is an int.  I don't see how could
> that be wrong, but maybe declare `flags' unsigned and see if that
> helps.

The problem (according to gcc) is that we have an expression like
this, with types instead of variable:

bool ? some_type_I_am_not_sure_which_but_seems_to_be_signed : short unsigned

Note that gcc are talking about the resulting types, not the types in
the boolean expression (I think).

So is va_arg's type signed? Or is it supposed to depend on the second
argument?


Right,

						MartinS

- Raw text -