This is the mail archive of the
cygwin-apps
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat