On Apr 15 02:48, Brian Dessent wrote: > Corinna Vinschen wrote: > > > They do? How and Why? Is that something which should be rather fixed > > in newlib instead of in the autogen configuration? > > The BSD implementation of funopen() doesn't explicitly define any types > for the cookie functions, but simply says they should match the > signatures of read(2), write(2), lseek(2), and close(2). Autogen tried > to define the following if it detected that funopen() exists: > > typedef int (cookie_read_function_t )(void *, char *, int); > typedef int (cookie_write_function_t)(void *, const char *, int); > typedef fpos_t (cookie_seek_function_t )(void *, fpos_t, int); > typedef int (cookie_close_function_t)(void *); > > However the newlib implementation explicitly defines these types as: > > typedef ssize_t cookie_read_function_t(void *__cookie, char *__buf, size_t > __n); > typedef ssize_t cookie_write_function_t(void *__cookie, const char *__buf, > size_t __n); > # ifdef __LARGE64_FILES > typedef int cookie_seek_function_t(void *__cookie, _off64_t *__off, int > __whence); > # else > typedef int cookie_seek_function_t(void *__cookie, off_t *__off, int > __whence); > # endif /* !__LARGE64_FILES */ > typedef int cookie_close_function_t(void *__cookie); > > So you got an error because the types differ. I don't see anything > wrong with the newlib definitions here, as they match the prototypes > of read/write/etc. I'm not sure why autogen was trying to define them > using int instead of size_t or ssize_t, but that's what it was doing > and it was apparently succeeding because the BSD headers didn't have > any typedefs.
I see. So what we have in newlib is how it's defined on Linux. Howver, shouldn't autogen have the same problem on Linux then? If not, any idea why? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
