From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Ken Brown <kbrown@cornell.edu>
Cc: 11508@debbugs.gnu.org
Subject: bug#11508: 24.1.50; Off-by-one error in xg_select?
Date: Sat, 19 May 2012 10:29:32 +0200 [thread overview]
Message-ID: <73ED1C31-12C1-4424-9DEC-632A1F0050D4@swipnet.se> (raw)
In-Reply-To: <3B902B7C-C59A-4933-A6AA-E23DB052704C@swipnet.se>
Hello.
Disregard my previous comment, I didn't look carefully enough.
The case where max_fds does not get increased in line 78 or 83 is very rare. Everytime some X connection is active, GLib will have added at least one fd (for signal handling). Probably
So the question is, is it more effective to give select the exact value (select works fine if nfds has a higher value than strictly neccessary), or always increment by one in lines 78 and 83?
As the normal case is that there will be several file descriptors in GLib, I'd say that the code does the most efficent thing most of the time.
Jan D.
>
> I think you misunderstand how select works. Here is a snippet from the BSD man page:
>
> "The first nfds descriptors are checked in
> each set; i.e., the descriptors from 0 through nfds-1 in the descriptor
> sets are examined. (Example: If you have set two file descriptors "4"
> and "17", nfds should not be "2", but rather "17 + 1" or "18".) "
>
>
> Jan D.
>
> 18 maj 2012 kl. 15:13 skrev Ken Brown:
>
>> I apologize in advance for the noise if I'm misunderstanding something,
>> but it seems to me that there is an error in the calculation of the
>> first argument in the call to select in xgselect.c:105. (Line numbers
>> refer to the current trunk; xgselect.c was last changed in bzr revno
>> 108249.)
>>
>> The parameter "max_fds" in xg_select, in spite of its name, is initially
>> 1 higher than the maximal file descriptor in the fd_sets in the other
>> parameters. If max_fds doesn't get increased in line 78 or 83, then
>> line 104 does the wrong thing, causing the first argument to select in
>> line 105 to be 1 higher than it should be.
>>
>> I think the following patch fixes this. It also renames "max_fds" to
>> "fds_lim" to more accurately reflect what it represents.
>>
>> === modified file 'src/xgselect.c'
>> --- src/xgselect.c 2012-05-16 02:22:53 +0000
>> +++ src/xgselect.c 2012-05-18 12:28:27 +0000
>> @@ -32,7 +32,7 @@
>> static ptrdiff_t gfds_size;
>>
>> int
>> -xg_select (int max_fds, SELECT_TYPE *rfds, SELECT_TYPE *wfds, SELECT_TYPE *efds,
>> +xg_select (int fds_lim, SELECT_TYPE *rfds, SELECT_TYPE *wfds, SELECT_TYPE *efds,
>> EMACS_TIME *timeout)
>> {
>> SELECT_TYPE all_rfds, all_wfds;
>> @@ -41,10 +41,10 @@
>> GMainContext *context;
>> int have_wfds = wfds != NULL;
>> int n_gfds = 0, our_tmo = 0, retval = 0, our_fds = 0;
>> - int i, nfds, fds_lim, tmo_in_millisec;
>> + int i, nfds, tmo_in_millisec;
>>
>> if (inhibit_window_system || !display_arg)
>> - return select (max_fds, rfds, wfds, efds, timeout);
>> + return select (fds_lim, rfds, wfds, efds, timeout);
>>
>> if (rfds) memcpy (&all_rfds, rfds, sizeof (all_rfds));
>> else FD_ZERO (&all_rfds);
>> @@ -75,12 +75,12 @@
>> if (gfds[i].events & G_IO_IN)
>> {
>> FD_SET (gfds[i].fd, &all_rfds);
>> - if (gfds[i].fd > max_fds) max_fds = gfds[i].fd;
>> + if (gfds[i].fd >= fds_lim) fds_lim = gfds[i].fd + 1;
>> }
>> if (gfds[i].events & G_IO_OUT)
>> {
>> FD_SET (gfds[i].fd, &all_wfds);
>> - if (gfds[i].fd > max_fds) max_fds = gfds[i].fd;
>> + if (gfds[i].fd >= fds_lim) fds_lim = gfds[i].fd + 1;
>> have_wfds = 1;
>> }
>> }
>> @@ -101,7 +101,6 @@
>> if (our_tmo) tmop = &tmo;
>> }
>>
>> - fds_lim = max_fds + 1;
>> nfds = select (fds_lim, &all_rfds, have_wfds ? &all_wfds : NULL, efds, tmop);
>>
>> if (nfds < 0)
>>
>>
>>
>>
>
next prev parent reply other threads:[~2012-05-19 8:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-18 13:13 bug#11508: 24.1.50; Off-by-one error in xg_select? Ken Brown
2012-05-19 8:05 ` Jan Djärv
2012-05-19 8:29 ` Jan Djärv [this message]
2012-05-19 9:52 ` Andreas Schwab
2012-05-20 22:44 ` Ken Brown
2012-05-21 5:30 ` Jan Djärv
2012-05-21 13:38 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73ED1C31-12C1-4424-9DEC-632A1F0050D4@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=11508@debbugs.gnu.org \
--cc=kbrown@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.