forked from osmocom/wireshark
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:
parent
d1847f0b49
commit
37649c4d0f
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue