doc: fix typos.

Change-Id: Id34affcb33c00e224dafbccc347b1d91b9e74c8d
Reviewed-on: https://code.wireshark.org/review/16914
Reviewed-by: Michael Mann <mmann78@netscape.net>
This commit is contained in:
Dario Lombardo 2016-08-05 22:00:05 +02:00 committed by Michael Mann
parent d1847f0b49
commit 37649c4d0f
4 changed files with 10 additions and 10 deletions

View File

@ -1135,7 +1135,7 @@ Note that the formats used must all belong to the same group as defined below:
- FT_OID, FT_REL_OID and FT_SYSTEM_ID
Any field not in a grouping above should *NOT* be used in duplicate field
abbrevations. The current code does not prevent it, but someday in the future
abbreviations. The current code does not prevent it, but someday in the future
it might.
The HFILL macro at the end of the struct will set reasonable default values

View File

@ -148,7 +148,7 @@ plugin_ldadd = $(_CUSTOM_plugin_ldadd_) \
3.2.3 Changes to the top level configure.ac
You need to add your plugins Makefile (in alphbetical order) to the
You need to add your plugins Makefile (in alphabetical order) to the
AC_OUTPUT rule in the configure.ac
AC_OUTPUT(
@ -328,14 +328,14 @@ The menu entries themselves are generated with the following code structure:
NULL, menu_cb, <user_data>);
This will not work with the GTK version on OS X; the GTK interface is
currently not supported on this plattform. The Qt interface on OS X
currently not supported on this platform. The Qt interface on OS X
provides the menu.
For a more detailed information, please refer to plugin_if.h
6.2 Implement interactions with the main interface
Due to memory constraints on most plattforms, plugin functionality cannot be
Due to memory constraints on most platforms, plugin functionality cannot be
called directly from a DLL context. Instead special functions will be used, which
will implement certain options for plugins to utilize.

View File

@ -39,7 +39,7 @@ memory in that pool is unconditionally freed. When you choose to allocate memory
in a pool, you *must* be aware of its lifetime: if the lifetime is shorter than
you need, your code will contain use-after-free bugs; if the lifetime is longer
than you need, your code may contain undetectable memory leaks. In either case,
the risks outweight the benefits.
the risks outweigh the benefits.
If no pool exists whose lifetime matches the lifetime of your memory, you have
two options: create a new pool (see section 3 of this document) or use the NULL
@ -264,7 +264,7 @@ similar to their standard-library namesakes. Each one takes an extra parameter
that is a copy of the allocator's private_data pointer.
Note that wrealloc() and wfree() are not expected to be called directly by user
code in most cases - they are primarily optimisations for use by data
code in most cases - they are primarily optimizations for use by data
structures that wmem might want to implement (it's inefficient, for example, to
implement a dynamically sized array without some form of realloc).
@ -354,7 +354,7 @@ intimately familiar with Glib's testing framework, but it does the job.
5. A Note on Performance
Because of my own bad judgement, there is the persistent idea floating around
Because of my own bad judgment, there is the persistent idea floating around
that wmem is somehow magically faster than other allocators in the general case.
This is false.

View File

@ -227,7 +227,7 @@ for each event type, instead of a single register() with the event as an
argument. For example there's a register_postdissector() function. In some
cases the Lua functions are invoked based on a pre-defined function-name model
instead of explicit register_foo(), whereby a C-object looks for a defined
member variable in the Registry that repesents a Lua function created by the
member variable in the Registry that represents a Lua function created by the
plugin. This would be the case if the Lua plugin had defined a pre-defined
member key of its object's table in Lua, for that purpose. For example if the
Lua plugin sets the 'reset' member of the Listener object table to a function,
@ -456,7 +456,7 @@ Example:
WSLUA_MOREARGS - a documentation-only macro used to document that more
arguments are expected/supported. This is useful when the number of
argumeents is not fixed, i.e., a vararg model. The macro is followed by the
arguments is not fixed, i.e., a vararg model. The macro is followed by the
name of the function it's an argument for (without the 'wslua_' prefix if the
function is a WSLUA_FUNCTION type), and then followed by descriptive text.
@ -470,7 +470,7 @@ Example:
WSLUA_RETURN - a macro with parentheses containing the number of return
values, meaning the number of items pushed back to Lua. Lua supports mutliple
values, meaning the number of items pushed back to Lua. Lua supports multiple
return values, although Wireshark usually just returns 0 or 1 value. The
argument can be an integer or a variable of the integer, and is not actually
documented. The API documentation will use the comments after this macro for