From d5d7525285969a6e33c8813cbffc71c379d18613 Mon Sep 17 00:00:00 2001
From: Andy Lindeman <alindeman@php.net>
Date: Fri, 16 May 2003 21:52:58 +0000
Subject: [PATCH] bit o' grammar/spelling

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@127358 c90b9560-bf6c-de11-be94-00142212c4b1
---
 chapters/security.xml | 8 ++++----
 security/index.xml    | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/chapters/security.xml b/chapters/security.xml
index fc367ec38f..a7b6556026 100644
--- a/chapters/security.xml
+++ b/chapters/security.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="iso-8859-1"?>
-<!-- $Revision: 1.53 $ -->
+<!-- $Revision: 1.54 $ -->
  <chapter id="security">
   <title>Security</title>
 
@@ -1035,9 +1035,9 @@ if ($good_login == 1) { // If above test fails, not initialized or checked befor
    <para>
     When on, register_globals will inject (poison) your scripts will all
     sorts of variables, like request variables from html forms.  This
-    coupled with the fact that PHP doesn't require variable initializion
+    coupled with the fact that PHP doesn't require variable initialization
     means writing insecure code is that much easier.  It was a difficult
-    decision but the PHP community decided to disable this directive by 
+    decision, but the PHP community decided to disable this directive by 
     default.  When on, people use variables yet really don't know for sure
     where they come from and can only assume.  Internal variables that are
     defined in the script itself get mixed up with request data sent by
@@ -1069,7 +1069,7 @@ if ($authorized) {
    <para>
     When register_globals = on, our logic above may be compromised.  When
     off, <varname>$authorized</varname> can't be set via request so it'll
-    be okay although it really is good general programming practice to 
+    be fine, although it really is generally a good programming practice to 
     initialize variables first.  For example, in our example above we might
     have first done <literal>$authorized = false</literal>.  Doing this
     first means our above code would work with register_globals on or off as 
diff --git a/security/index.xml b/security/index.xml
index fc367ec38f..a7b6556026 100644
--- a/security/index.xml
+++ b/security/index.xml
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="iso-8859-1"?>
-<!-- $Revision: 1.53 $ -->
+<!-- $Revision: 1.54 $ -->
  <chapter id="security">
   <title>Security</title>
 
@@ -1035,9 +1035,9 @@ if ($good_login == 1) { // If above test fails, not initialized or checked befor
    <para>
     When on, register_globals will inject (poison) your scripts will all
     sorts of variables, like request variables from html forms.  This
-    coupled with the fact that PHP doesn't require variable initializion
+    coupled with the fact that PHP doesn't require variable initialization
     means writing insecure code is that much easier.  It was a difficult
-    decision but the PHP community decided to disable this directive by 
+    decision, but the PHP community decided to disable this directive by 
     default.  When on, people use variables yet really don't know for sure
     where they come from and can only assume.  Internal variables that are
     defined in the script itself get mixed up with request data sent by
@@ -1069,7 +1069,7 @@ if ($authorized) {
    <para>
     When register_globals = on, our logic above may be compromised.  When
     off, <varname>$authorized</varname> can't be set via request so it'll
-    be okay although it really is good general programming practice to 
+    be fine, although it really is generally a good programming practice to 
     initialize variables first.  For example, in our example above we might
     have first done <literal>$authorized = false</literal>.  Doing this
     first means our above code would work with register_globals on or off as