Bruno Haible wrote:
> And this implements the modules for most of the functions from .
>
> The functions 'ioctl' and 'close' are not handled in this patch; they are a
> little more complicated.
I'll take care of close.
Paolo
Bruno Haible <[EMAIL PROTECTED]> writes:
> And this implements the modules for most of the functions from .
Looks fine to me, thanks.
/Simon
And this implements the modules for most of the functions from .
The functions 'ioctl' and 'close' are not handled in this patch; they are a
little more complicated.
2008-10-05 Bruno Haible <[EMAIL PROTECTED]>
* modules/accept: New file.
* modules/bind: New file.
* modu
Paolo Bonzini wrote:
> What I meant was, having a link warning like for
> other gnulib modules would be good *even when you are not under mingw*
> (i.e. even where select works).
OK, I see. I'm adding this as a link warning conditionalized by
GNULIB_POSIXCHECK. I cannot make it unconditional, othe
Bruno Haible wrote:
> Paolo Bonzini wrote:
>>> Here is a proposal that should acknowledge both of your arguments:
>>> Provide separate modules 'select' separate from 'sys_select', like we do
>>> in the rest of gnulib, but if 'sys_select' is used without 'select', then
>>> #define select select_us
Paolo Bonzini wrote:
> > Here is a proposal that should acknowledge both of your arguments:
> > Provide separate modules 'select' separate from 'sys_select', like we do
> > in the rest of gnulib, but if 'sys_select' is used without 'select', then
> > #define select select_used_without_requesting_
Bruno Haible <[EMAIL PROTECTED]> writes:
> Is this acceptable to both of you?
Yes, I like it.
I believe the approach would break in GnuTLS which uses its own
select-replacement for Mingw32, or at least trigger a warning about
re-#define'ing select, but I'll deal with that by using the select
mod
Ben Pfaff wrote:
> I do not understand why one would include just for
> struct timeval. Isn't a more straightforward
> choice? There is already a sys_time module.
Yes, right. The argument was a bit hypothetical. The main argument,
regarding , is consistency with the rest of gnulib:
one module
Bruno Haible <[EMAIL PROTECTED]> writes:
> As far as I understood, basically, Simon wants
> a module 'select' separate from 'sys_select' because
> - it's cleaner,
> - the guy who needs just for 'struct timeval' does not
> need the select() function.
I do not understand why one would incl
> Here is a proposal that should acknowledge both of your arguments:
> Provide separate modules 'select' separate from 'sys_select', like we do
> in the rest of gnulib, but if 'sys_select' is used without 'select', then
> #define select select_used_without_requesting_gnulib_module_select
> so th
Hi Paolo, Simon,
You discussed on 2008-09-23. As far as I understood, basically, Simon wants
a module 'select' separate from 'sys_select' because
- it's cleaner,
- the guy who needs just for 'struct timeval' does not
need the select() function.
Paolo wants sys_select to provide 'select'
> In this case, the tradition is that the gnulib module
> name is named after the function and not the header file, though, so
> possibly you could rename sys_select to select? Maybe it is not worth
> the breakage though, you decide.
Maybe later. I also think it should be renamed, but I'm not su
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> the stdio module [...]
>> does not pull in the fopen module, even though the fopen module
>> makes fopen function work *the way anyone including stdio.h would
>> expect them work*.
>
> I disagree on the "anyone" part. I never missed the fopen module, b
> the stdio module [...]
> does not pull in the fopen module, even though the fopen module
> makes fopen function work *the way anyone including stdio.h would
> expect them work*.
I disagree on the "anyone" part. I never missed the fopen module, but
I'm sure everyone who wrote cross-platform soc
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>> The difference is that without these fixes, winsock is simply just too
>>> crippled for the casual Unix programmer. Providing sys/socket.h and
>>> sys/select.h without anything like these wrappers was just giving a
>>> false sense of portability.
>>
>> The difference is that without these fixes, winsock is simply just too
>> crippled for the casual Unix programmer. Providing sys/socket.h and
>> sys/select.h without anything like these wrappers was just giving a
>> false sense of portability.
>
> I think that is consistent with how gnulib wo
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> Compare other header files and system
>> functions for how to do it, e.g., stdio.in.h and fopen: the replacement
>> for fopen isn't pulled in by the stdio-h module normally, but the
>> stdio.in.h code helps the fopen module when in use.
>>
>> Possibly
> I don't think this code should be built just because someone wanted the
> sys/socket.h header and added the sys_socket module. There are many
> places you want the sys/socket.h header without calling select.
Ok, I'll place it into sys_select instead.
> Compare other header files and system
>
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Tested under Wine. I'd appreciate more testing before committing it.
I don't think this code should be built just because someone wanted the
sys/socket.h header and added the sys_socket module. There are many
places you want the sys/socket.h header wi
Here is the patch to recycle some of the code in poll.c (much less
than I expected) to implement select(2). The code duplication between
the files is limited to one function (win32_compute_revents vs.
win32_poll_handle); should I add a note that changes to one should
be replicated in the other?
H
20 matches
Mail list logo
