This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: m68k: conflicting types for 'read'


On Aug  3 18:22, Anders Montonen wrote:
> 
> On Aug 3, 2014, at 17:08, Joel Sherrill wrote:
> > On August 3, 2014 5:48:24 AM CDT, Anders Montonen <Anders.Montonen@iki.fi> wrote:
> >> Hi,
> >> 
> >> When trying to compile newlib 2.1.0 for a m68k-unknown-elf target using
> >> GCC 4.9.1 (same behaviour with GCC 4.8.3), the build fails with an
> >> error about conflicting types for the read function. Newlib 2.0.0
> >> compiles without errors.
> >> 
> >> /Users/anders/work/toolchain/gcc/4.9.1/m68k-elf/./gcc/xgcc
> >> -B/Users/anders/work/toolchain/gcc/4.9.1/m68k-elf/./gcc/ -nostdinc
> >> -B/Users/anders/work/toolchain/gcc/4.9.1/m68k-elf/m68k-elf/newlib/
> >> -isystem
> >> /Users/anders/work/toolchain/gcc/4.9.1/m68k-elf/m68k-elf/newlib/targ-include
> >> -isystem
> >> /Users/anders/work/toolchain/gcc/4.9.1/gcc-4.9.1/newlib/libc/include
> >> -B/Users/anders/work/toolchain/gcc/4.9.1/m68k-elf/m68k-elf/libgloss/m68k
> >> -L/Users/anders/work/toolchain/gcc/4.9.1/m68k-elf/m68k-elf/libgloss/libnosys
> >> -L/Users/anders/work/toolchain/gcc/4.9.1/gcc-4.9.1/libgloss/m68k
> >> -B/Users/anders/local/m68k-elf/bin/ -B/Users/anders/local/m68k-elf/lib/
> >> -isystem /Users/anders/local/m68k-elf/include -isystem
> >> /Users/anders/local/m68k-elf/sys-include    -g -O2 -g -O2  -mcpu=51qe
> >> -DHOSTED=1 -I. -I../../../../../gcc-4.9.1/libgloss/m68k/.. -c
> >> ../../../../../gcc-4.9.1/libgloss/m68k/io-read.c -o hosted-read.o
> >> ../../../../../gcc-4.9.1/libgloss/m68k/io-read.c:33:9: error:
> >> conflicting types for 'read'
> >> ssize_t read (int fd, void *buf, size_t count)
> >>        ^
> >> In file included from
> >> /Users/anders/work/toolchain/gcc/4.9.1/gcc-4.9.1/newlib/libc/include/sys/unistd.h:8:0,
> >> from
> >> /Users/anders/work/toolchain/gcc/4.9.1/gcc-4.9.1/newlib/libc/include/unistd.h:4,
> >>             from ../../../../../gcc-4.9.1/libgloss/m68k/io-read.c:17:
> >> /Users/anders/work/toolchain/gcc/4.9.1/gcc-4.9.1/newlib/libc/include/sys/unistd.h:144:25:
> >> note: previous declaration of 'read' was here
> >> _READ_WRITE_RETURN_TYPE _EXFUN(read, (int __fd, void *__buf, size_t
> >> __nbyte ));
> > 
> > What is _READ_WRITE_RETURN_TYPE defined to for this target? I recall
> > that ssize_t is correct because -1 can be returned.

It's a glitch in libgloss/m68k/io-read.c in the first place, I think.
It would be better to define read as returning _READ_WRITE_RETURN_TYPE,
that would make it independent of the actual type used.

> If I'm reading the sources right, it falls under the default 'int'
> case in sys/config.h. This has not changed between 2.0.0 and 2.1.0.
> However, I suspect that in sys/_types.h, _ssize_t is now typedef'd
> from GCC's __SIZE_TYPE__ instead of int as before.

I'm wondering in how far "int" is still a good default.  On legacy
systems ssize_t will probably be equivalent to int anyway and if not,
it can be easily overridden.

So, what if we make ssize_t the default and require legacy targets to
add the #define _READ_WRITE_RETURN_TYPE int?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgpC6Oi_qeIla.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]