[PATCH] doc: Fix typo

[PATCH] doc: Fix typo

[Segher Boessenkool]

From: Joerg Sonnenberger <joerg@bec.de>

I committed this patch for a typo spotted by Joerg Sonnenbecker:

2020-04-01  Joerg Sonnenberger  <joerg@bec.de>

	* doc/extend.texi (Common Function Attributes): Fix typo.
---
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f1f2064..bde3748 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2545,7 +2545,7 @@ __attribute__ ((access (read_write, 1), access (read_only, 2))) char* strcat (ch
 The @code{write_only} access mode applies to arguments of pointer types
 without the @code{const} qualifier.  It specifies that the pointer to which
 it applies is used to write to the referenced object but not read from it.
-The object refrenced by the pointer need not be initialized.  An example
+The object referenced by the pointer need not be initialized.  An example
 of the use of the @code{write_only} access mode is the first argument to
 the @code{strcpy} function, or the first two arguments to the @code{fgets}
 function.
-- 
1.8.3.1

[PATCH, doc]: Fix typo.

[Ben Elliston]

I'm committing the following as obvious.  I'm reasonably certain to have
got the intended meaning correct here, but if I haven't, please let me
know.  In the meantime, I don't think this patch will make things
worse. :-)

Cheers, Ben

2008-04-01  Ben Elliston  <bje@au.ibm.com>

        * doc/c-tree.texi (Function Basics): Fix grammatical error.

Index: doc/c-tree.texi
===================================================================
--- doc/c-tree.texi     (revision 133784)
+++ doc/c-tree.texi     (working copy)
@@ -1508,7 +1508,7 @@ whose @code{TREE_VALUE} represents a typ
 
 @item TYPE_NOTHROW_P
 This predicate holds when the exception-specification of its arguments
-if of the form `@code{()}'.
+is of the form `@code{()}'.
 
 @item DECL_ARRAY_DELETE_OPERATOR_P
 This predicate holds if the function an overloaded

Re: [PATCH, doc]: Fix typo.

[Tom Browder]

On Tue, Apr 1, 2008 at 12:31 AM, Ben Elliston <bje@au1.ibm.com> wrote:
> I'm committing the following as obvious.  I'm reasonably certain to have
>  got the intended meaning correct here, but if I haven't, please let me
>  know.  In the meantime, I don't think this patch will make things
>  worse. :-)

Ben, could I get your support for this attempted patch for the same
file?  Joseph is very busy, but this is one the order of yours.

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00102.html

Thanks.

-Tom

Tom Browder
Niceville, Florida
USA

Re: [PATCH, doc]: Fix typo.

[Ben Elliston]

> Ben, could I get your support for this attempted patch for the same
> file?  Joseph is very busy, but this is one the order of yours.
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00102.html

Sorry, Tom, I don't think this qualifies as obvious and I cannot approve
it -- this is not an area I am a maintainer of.  If you're still after
approval, I suggest sending a ping and Cc'ing the maintainers you think
cover the change (probably Joseph).

Cheers, Ben

Re: [PATCH, doc]: Fix typo.

[Gerald Pfeifer]

On Wed, 2 Apr 2008, Ben Elliston wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00102.html
> Sorry, Tom, I don't think this qualifies as obvious and I cannot approve 
> it -- this is not an area I am a maintainer of.

When it comes to documentation, we're generally not that strict. :-)

That said: Tom, I believe the patch introduces a number of problems 
coming from too mechanical an approach.

Specifically, in 

 -continues until a non-array type is found, and the qualification of this
 -type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold of
 -the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
 +continues until a non-array type is found and the qualification of its
 +type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold
 +for the type @code{const int ()[7]}, denoting an array of seven @code{int}s.

the part that replaces "this type" by "its type" doesn't seem right.
And in 

  Used to mark the beginning (if @code{CTOR_BEGIN_P} holds) or end (if
 -@code{CTOR_END_P} holds of the main body of a constructor.  See also
 +@code{CTOR_END_P} holds) for the main body of a constructor.  See also
  @code{SUBOBJECT} for more information on how to use these nodes.

adding the closing parenthesis is a valid fix, but replacing "of" by
"for" does not seem right.

The patch is fine (approved) if you fix these two aspects.

Thanks,
Gerald

Re: [PATCH, doc]: Fix typo.

[Tom Browder]

On Sun, Apr 6, 2008 at 1:44 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Wed, 2 Apr 2008, Ben Elliston wrote:
>  >> http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00102.html
>  > Sorry, Tom, I don't think this qualifies as obvious and I cannot approve
>  > it -- this is not an area I am a maintainer of.
>
>  When it comes to documentation, we're generally not that strict. :-)
>
>  That said: Tom, I believe the patch introduces a number of problems
>  coming from too mechanical an approach.
>
>  Specifically, in
>
>   -continues until a non-array type is found, and the qualification of this
>   -type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold of
>   -the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
>   +continues until a non-array type is found and the qualification of its
>   +type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold
>   +for the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
>
>  the part that replaces "this type" by "its type" doesn't seem right.
>  And in

OK, I agree.

>
>   Used to mark the beginning (if @code{CTOR_BEGIN_P} holds) or end (if
>   -@code{CTOR_END_P} holds of the main body of a constructor.  See also
>   +@code{CTOR_END_P} holds) for the main body of a constructor.  See also
>   @code{SUBOBJECT} for more information on how to use these nodes.
>
>  adding the closing parenthesis is a valid fix, but replacing "of" by
>  "for" does not seem right.

I agree.  After I closed the parenthetical expression I failed to
reread the sentence.  Now the 'of' makes perfect sense.

>  The patch is fine (approved) if you fix these two aspects.

I'll do that.

Thanks, Gerald.

-Tom