This is the mail archive of the glibc-cvs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GNU C Library master sources branch master updated. glibc-2.23-479-g3ef569c


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  3ef569c71b66fc2820afba3819a53d580c47eedc (commit)
      from  228a78c21b9ed27004a1ccb5bd48a3263d7cd67d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=3ef569c71b66fc2820afba3819a53d580c47eedc

commit 3ef569c71b66fc2820afba3819a53d580c47eedc
Author: Rical Jasan <ricaljasan@pacific.net>
Date:   Fri May 6 00:54:31 2016 -0700

    manual: fix typos in the memory chapter
    
    Some of these are obvious grammar fixes while others fix references
    to the function prototypes.

diff --git a/ChangeLog b/ChangeLog
index a4a1cea..4f4591e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2016-06-16  Rical Jasan  <ricaljasan@pacific.net>
+
+	* manual/memory.texi: Fix various typos & grammar errors.
+
 2016-06-14  Joseph Myers  <joseph@codesourcery.com>
 
 	[BZ #20255]
diff --git a/manual/memory.texi b/manual/memory.texi
index 92f041a..5383105 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -158,7 +158,7 @@ grows, but doesn't shrink when the stack shrinks.
 
 This section covers how ordinary programs manage storage for their data,
 including the famous @code{malloc} function and some fancier facilities
-special @theglibc{} and GNU Compiler.
+special to @theglibc{} and GNU Compiler.
 
 @menu
 * Memory Allocation and C::     How to get different kinds of allocation in C.
@@ -997,7 +997,7 @@ The @code{memalign} function returns a null pointer on error and sets
 There was insufficient memory available to satisfy the request.
 
 @item EINVAL
-@var{alignment} is not a power of two.
+@var{boundary} is not a power of two.
 
 @end table
 
@@ -1066,7 +1066,7 @@ systems that do not support @w{ISO C11}.
 @c  _int_memalign dup @acsfd @acsmem
 @c  mutex_unlock dup @aculock
 Using @code{valloc} is like using @code{memalign} and passing the page size
-as the value of the second argument.  It is implemented like this:
+as the value of the first argument.  It is implemented like this:
 
 @smallexample
 void *
@@ -1608,7 +1608,7 @@ Return information about the current dynamic memory usage.
 
 A complicated task when programming with languages which do not use
 garbage collected dynamic memory allocation is to find memory leaks.
-Long running programs must assure that dynamically allocated objects are
+Long running programs must ensure that dynamically allocated objects are
 freed at the end of their lifetime.  If this does not happen the system
 runs out of memory, sooner or later.
 
@@ -1709,7 +1709,7 @@ main (int argc, char *argv[])
 @}
 @end example
 
-This is all what is needed if you want to trace the calls during the
+This is all that is needed if you want to trace the calls during the
 whole runtime of the program.  Alternatively you can stop the tracing at
 any time with a call to @code{muntrace}.  It is even possible to restart
 the tracing again with a new call to @code{mtrace}.  But this can cause
@@ -1718,8 +1718,8 @@ not called.  Please note that not only the application uses the traced
 functions, also libraries (including the C library itself) use these
 functions.
 
-This last point is also why it is no good idea to call @code{muntrace}
-before the program terminated.  The libraries are informed about the
+This last point is also why it is not a good idea to call @code{muntrace}
+before the program terminates.  The libraries are informed about the
 termination of the program only after the program returns from
 @code{main} or calls @code{exit} and so cannot free the memory they use
 before this time.
@@ -2147,7 +2147,7 @@ in the same obstack.
 If @var{object} is a null pointer, everything allocated in the obstack
 is freed.  Otherwise, @var{object} must be the address of an object
 allocated in the obstack.  Then @var{object} is freed, along with
-everything allocated in @var{obstack} since @var{object}.
+everything allocated in @var{obstack-ptr} since @var{object}.
 @end deftypefun
 
 Note that if @var{object} is a null pointer, the result is an
@@ -2392,7 +2392,7 @@ in the current chunk.  It is declared as follows:
 @safety{@prelim{}@mtsafe{@mtsrace{:obstack-ptr}}@assafe{}@acsafe{}}
 This returns the number of bytes that can be added safely to the current
 growing object (or to an object about to be started) in obstack
-@var{obstack} using the fast growth functions.
+@var{obstack-ptr} using the fast growth functions.
 @end deftypefun
 
 While you know there is room, you can use these fast growth functions
@@ -2802,7 +2802,7 @@ open-coded by the GNU C compiler.)
 
 @item
 Since @code{alloca} does not have separate pools for different sizes of
-block, space used for any size block can be reused for any other size.
+blocks, space used for any size block can be reused for any other size.
 @code{alloca} does not cause memory fragmentation.
 
 @item
@@ -2921,7 +2921,7 @@ The address of the end of a segment is defined to be the address of the
 last byte in the segment plus 1.
 
 The function has no effect if @var{addr} is lower than the low end of
-the data segment.  (This is considered success, by the way).
+the data segment.  (This is considered success, by the way.)
 
 The function fails if it would cause the data segment to overlap another
 segment or exceed the process' data storage limit (@pxref{Limits on
@@ -3243,7 +3243,7 @@ with @code{munlockall} and @code{munlock}.
 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
 
 @code{munlockall} unlocks every page in the calling process' virtual
-address space and turn off @code{MCL_FUTURE} future locking mode.
+address space and turns off @code{MCL_FUTURE} future locking mode.
 
 The return value is zero if the function succeeds.  Otherwise, it is
 @code{-1} and @code{errno} is set accordingly.  The only way this

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog          |    4 ++++
 manual/memory.texi |   24 ++++++++++++------------
 2 files changed, 16 insertions(+), 12 deletions(-)


hooks/post-receive
-- 
GNU C Library master sources


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]