This is the mail archive of the
mailing list for the Cygwin project.
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
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 Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com