DOC: Replace deprecated (since 1.6) references in documentation

and fixed two broken links because they started with "&". [skip ci]

2 files changed, 6 insertions, 6 deletions

diff --git a/doc/source/user/c-info.beyond-basics.rst b/doc/source/user/c-info.beyond-basics.rst
index 82a6c359d..e91f23182 100644
--- a/doc/source/user/c-info.beyond-basics.rst
+++ b/doc/source/user/c-info.beyond-basics.rst
@@ -428,10 +428,10 @@ type-object structure and populating it with functions and pointers to
 describe the desired behavior of the type. Typically, a new
 C-structure is also created to contain the instance-specific
 information needed for each object of the type as well. For example,
-:c:data:`&PyArray_Type` is a pointer to the type-object table for the ndarray
+:c:data:`&PyArray_Type<PyArray_Type>` is a pointer to the type-object table for the ndarray
 while a :c:type:`PyArrayObject *` variable is a pointer to a particular instance
 of an ndarray (one of the members of the ndarray structure is, in
-turn, a pointer to the type- object table :c:data:`&PyArray_Type`). Finally
+turn, a pointer to the type- object table :c:data:`&PyArray_Type<PyArray_Type>`). Finally
 :c:func:`PyType_Ready` (<pointer_to_type_object>) must be called for
 every new Python type.
 
diff --git a/doc/source/user/c-info.how-to-extend.rst b/doc/source/user/c-info.how-to-extend.rst
index b73dfbf54..6b7f95a84 100644
--- a/doc/source/user/c-info.how-to-extend.rst
+++ b/doc/source/user/c-info.how-to-extend.rst
@@ -385,9 +385,9 @@ writeable). The syntax is
         and 4) any scalar object (becomes a zero-dimensional
         array). Sub-classes of the ndarray that otherwise fit the
         requirements will be passed through. If you want to ensure
-        a base-class ndarray, then use :c:data:`NPY_ENSUREARRAY` in the
+        a base-class ndarray, then use :c:data:`NPY_ARRAY_ENSUREARRAY` in the
         requirements flag. A copy is made only if necessary. If you
-        want to guarantee a copy, then pass in :c:data:`NPY_ENSURECOPY`
+        want to guarantee a copy, then pass in :c:data:`NPY_ARRAY_ENSURECOPY`
         to the requirements flag.
 
     *typenum*
@@ -415,7 +415,7 @@ writeable). The syntax is
 
         The object will be converted to the desired type only if it
         can be done without losing precision. Otherwise ``NULL`` will
-        be returned and an error raised. Use :c:data:`NPY_FORCECAST` in the
+        be returned and an error raised. Use :c:data:`NPY_ARRAY_FORCECAST` in the
         requirements flag to override this behavior.
 
     *requirements*
@@ -575,7 +575,7 @@ is obtained as :c:func:`PyArray_GETPTR3` (E, i, j, k).
 
 As explained previously, C-style contiguous arrays and Fortran-style
 contiguous arrays have particular striding patterns. Two array flags
-(:c:data:`NPY_C_CONTIGUOUS` and :c:data:`NPY_F_CONTIGUOUS`) indicate
+(:c:data:`NPY_ARRAY_C_CONTIGUOUS` and :c:data:`NPY_ARRAY_F_CONTIGUOUS`) indicate
 whether or not the striding pattern of a particular array matches the
 C-style contiguous or Fortran-style contiguous or neither. Whether or
 not the striding pattern matches a standard C or Fortran one can be