Permalink
Browse files

Fix some typos

  • Loading branch information...
1 parent 9dda9a0 commit dacf41f84d207e044b5dd7712ecdf31d0261fc5c Robert Ransom committed with Nick Mathewson Feb 20, 2011
Showing with 17 additions and 16 deletions.
  1. +2 −2 Ref1_libsetup.txt
  2. +4 −3 Ref4_event.txt
  3. +1 −1 Ref5_evutil.txt
  4. +3 −3 Ref6_bufferevent.txt
  5. +1 −1 Ref8_listener.txt
  6. +5 −5 Ref9_dns.txt
  7. +1 −1 examples_R9/R9_multilookup.c
View
@@ -82,7 +82,7 @@ void set_logfile(FILE *f)
.NOTE
It is not safe to invoke Libevent functions from within a user-provided
-event_log_cb callback! For instance, if try to write a log callback that
+event_log_cb callback! For instance, if you try to write a log callback that
uses bufferevents to send warning messages to a network socket, you are
likely to run into strange and hard-to-diagnose bugs. This restriction may
be removed for some functions in a future version of Libevent.
@@ -289,7 +289,7 @@ library to implement:
- unlocking
- lock allocation
- lock destruction
-- Conditinos
+ - Conditions
- condition variable creation
- condition variable destruction
- waiting on a condition variable
View
@@ -255,8 +255,8 @@ Caveats when working with signals
With current versions of Libevent, with most backends, only one event_base
per process at a time can be listening for signals. If you add signal events
-to two event_bases at once ---even the signals are different!--- only one
-event_base will get the signals.
+to two event_bases at once ---even if the signals are different!--- only one
+event_base will receive signals.
The kqueue backend does not have this limitation.
@@ -281,7 +281,7 @@ structure.
These are _very_ small costs, and do not matter for most applications.
You should just stick to using event_new() unless you *know* that
you're incurring a significant performance penalty for heap-allocating
-your events. Not using this function can cause hard-to-diagnose errors
+your events. Using event_assign() can cause hard-to-diagnose errors
with future versions of Libevent if they use a larger event structure
than the one you're building with.
@@ -335,6 +335,7 @@ event_del() on it *before* you call event_assign() on it again.
There are convenience macros you can use to event_assign() a timeout-only or
a signal event:
+
.Interface
[code,C]
--------
View
@@ -434,7 +434,7 @@ If you are running in an environment where your program is likely to drop
privileges (for example, by running chroot()), you should call
evutil_secure_rng_init() before you do so.
-You can add more random bytes to the entropy poll yourself by calling
+You can add more random bytes to the entropy pool yourself by calling
evutil_secure_rng_add_bytes(); this shouldn't be necessary in typical
use.
View
@@ -361,7 +361,7 @@ void bufferevent_free(struct bufferevent *bev);
--------
This function frees a bufferevent. Bufferevents are internally
-reference counted, so if the bufferevent has pending deferred
+reference-counted, so if the bufferevent has pending deferred
callbacks when you free it, it won't be deleted until the callbacks
are done.
@@ -388,7 +388,7 @@ void bufferevent_setcb(struct bufferevent *bufev,
The bufferevent_setcb() function changes one or more of the callbacks
of a bufferevent. The readcb, writecb, and eventcb functions are
-called (respectively) when enough data is read, enough data is
+called (respectively) when enough data is read, when enough data is
written, or when an event occurs. The first argument of each is the
bufferevent that has had the event happen. The last argument is the
value provided by the user in the 'cbarg' parameter of
@@ -401,7 +401,7 @@ function. Note the all callback functions on a bufferevent share a
single 'cbarg' value, so changing it will affect all of them.
This function was introduced in Libevent 1.4.4. The type names
-"bufferevent_data_cb" and "bufferevet_event_cb" are new in Libevent
+"bufferevent_data_cb" and "bufferevent_event_cb" are new in Libevent
2.0.2-alpha.
.Interface
View
@@ -74,7 +74,7 @@ LEV_OPT_CLOSE_ON_EXEC::
If this option is set, the connection listener sets the
close-on-exec flag on the underlying listener socket. See your
platform documentation for fcntl and FD_CLOEXEC for more
- informatino.
+ information.
LEV_OPT_REUSEABLE::
By default on some platforms, once a listener socket is closed,
View
@@ -126,7 +126,7 @@ EVUTIL_AI_ADDRCONFIG::
addresses are only included in the result if the system has a
nonlocal IPv6 address.
-The ai_family filed of 'hints' is used to tell evutil_getaddrinfo() which
+The ai_family field of 'hints' is used to tell evutil_getaddrinfo() which
addresses it should return. It can be AF_INET to request IPv4 addresses
only, AF_INET6 to request IPv6 addresses only, or AF_UNSPEC to request
all available addresses.
@@ -300,7 +300,7 @@ struct evdns_getaddrinfo_request *evdns_getaddrinfo(
void evdns_getaddrinfo_cancel(struct evdns_getaddrinfo_request *req);
-----
-The evdns_getaddrinfo_function() behaves just like evutil_getaddrinfo(),
+The evdns_getaddrinfo() function behaves just like evutil_getaddrinfo(),
except that instead of blocking on DNS servers, it uses Libevent's
low-level DNS facilities to look hostnames up for you. Because it can't
always return you the result immediately, you need to provide it a
@@ -772,7 +772,7 @@ struct evdns_server_question {
};
------
-The 'flags' fieldn of the request contains the DNS flags set in the request;
+The 'flags' field of the request contains the DNS flags set in the request;
the 'nquestions' field is the number of questions in the request; and
'questions' is an array of pointers to struct evdns_server_question. Each
evdns_server_question includes the resource type of the request (see below
@@ -870,14 +870,14 @@ int evdns_server_request_add_reply(struct evdns_server_request *req,
This function adds an arbitrary RR to the DNS reply of a request 'req'.
The 'section' argument describes which section to add it to, and should be
-one of the EVDNS_*_SECTION values. The 'name' argument is the name field of
+one of the EVDNS_*\_SECTION values. The 'name' argument is the name field of
the RR. The 'type' argument is the 'type' field of the RR, and should be one
of the EVDNS_TYPE_* values if possible. The 'dns_class' argument is the
class field of the RR, and should generally be EVDNS_CLASS_INET. The 'ttl'
argument is the time-to-live in seconds of the RR. The rdata and rdlength
fields of the RR will be generated from the 'datalen' bytes provided in
'data'. If is_name is true, the data will be encoded as a DNS name (i.e.,
-with dns name compression). Otherwise, it's included verbatim.
+with DNS name compression). Otherwise, it's included verbatim.
.Interface
[code,C]
@@ -75,7 +75,7 @@ int main(int argc, char **argv)
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_flags = EVUTIL_AI_CANONNAME;
- /* Unless we specify a socktype, we'll get at leat two entries for
+ /* Unless we specify a socktype, we'll get at least two entries for
* each address: one for TCP and one for UDP. That's not what we
* want. */
hints.ai_socktype = SOCK_STREAM;

0 comments on commit dacf41f

Please sign in to comment.