doc: correct orthography eg. → e.g.

Author: JakobJingleheimer

deps/icu-small/source/i18n/indiancal.h

@@ -57,7 +57,7 @@ U_NAMESPACE_BEGIN
  *
  * The Years
  * Years are counted in the Saka Era, which starts its year 0 in 78AD (by gregorian calendar).
- * So for eg. 9th June 2006 by Gregorian Calendar, is same as 19th of Jyaistha in 1928 of Saka
+ * So for e.g. 9th June 2006 by Gregorian Calendar, is same as 19th of Jyaistha in 1928 of Saka
  * era by Indian National Calendar.
  * <p>
  * The Indian Calendar has only one allowable era: <code>Saka Era</code>.  If the
@@ -75,28 +75,28 @@ class U_I18N_API IndianCalendar : public Calendar {
    * @internal
    */
   enum EEras {
-    /** 
-     * Constant for Chaitra, the 1st month of the Indian year. 
+    /**
+     * Constant for Chaitra, the 1st month of the Indian year.
      */
       CHAITRA,
 
       /**
-     * Constant for Vaisakha, the 2nd month of the Indian year. 
+     * Constant for Vaisakha, the 2nd month of the Indian year.
      */
       VAISAKHA,
 
       /**
-     * Constant for Jyaistha, the 3rd month of the Indian year. 
+     * Constant for Jyaistha, the 3rd month of the Indian year.
      */
       JYAISTHA,
 
     /**
-     * Constant for Asadha, the 4th month of the Indian year. 
+     * Constant for Asadha, the 4th month of the Indian year.
      */
       ASADHA,
 
     /**
-     * Constant for Sravana, the 5th month of the Indian year. 
+     * Constant for Sravana, the 5th month of the Indian year.
      */
       SRAVANA,
 
@@ -105,33 +105,33 @@ class U_I18N_API IndianCalendar : public Calendar {
      */
       BHADRA,
 
-    /** 
-     * Constant for the Asvina, the 7th month of the Indian year. 
+    /**
+     * Constant for the Asvina, the 7th month of the Indian year.
      */
       ASVINA,
 
     /**
-     * Constant for Kartika, the 8th month of the Indian year. 
+     * Constant for Kartika, the 8th month of the Indian year.
      */
       KARTIKA,
 
     /**
-     * Constant for Agrahayana, the 9th month of the Indian year. 
+     * Constant for Agrahayana, the 9th month of the Indian year.
      */
       AGRAHAYANA,
 
     /**
-     * Constant for Pausa, the 10th month of the Indian year. 
+     * Constant for Pausa, the 10th month of the Indian year.
      */
       PAUSA,
 
     /**
-     * Constant for Magha, the 11th month of the Indian year. 
+     * Constant for Magha, the 11th month of the Indian year.
      */
       MAGHA,
 
     /**
-     * Constant for Phalguna, the 12th month of the Indian year. 
+     * Constant for Phalguna, the 12th month of the Indian year.
      */
       PHALGUNA
     };
@@ -173,7 +173,7 @@ class U_I18N_API IndianCalendar : public Calendar {
    * @internal
    */
   //void setCivil(ECivil beCivil, UErrorCode &status);
-    
+
   /**
    * Returns <code>true</code> if this object is using the fixed-cycle civil
    * calendar, or <code>false</code> if using the religious, astronomical
@@ -190,7 +190,7 @@ class U_I18N_API IndianCalendar : public Calendar {
 
  private:
   /**
-   * Determine whether a year is the gregorian year a leap year 
+   * Determine whether a year is the gregorian year a leap year
    */
   //static UBool isGregorianLeap(int32_t year);
   //----------------------------------------------------------------------
@@ -201,7 +201,7 @@ class U_I18N_API IndianCalendar : public Calendar {
    * @internal
    */
   virtual int32_t handleGetLimit(UCalendarDateFields field, ELimitType limitType) const override;
-  
+
   /**
    * Return the length (in days) of the given month.
    *
@@ -210,7 +210,7 @@ class U_I18N_API IndianCalendar : public Calendar {
    * @internal
    */
   virtual int32_t handleGetMonthLength(int32_t extendedYear, int32_t month, UErrorCode& status) const override;
-  
+
   /**
    * Return the number of days in the given Indian year
    * @internal
@@ -246,7 +246,7 @@ class U_I18N_API IndianCalendar : public Calendar {
    * <li>DAY_OF_MONTH
    * <li>DAY_OF_YEAR
    * <li>EXTENDED_YEAR</ul>
-   * 
+   *
    * The DAY_OF_WEEK and DOW_LOCAL fields are already set when this
    * method is called. The getGregorianXxx() methods return Gregorian
    * calendar equivalents for the given Julian day.
@@ -255,7 +255,7 @@ class U_I18N_API IndianCalendar : public Calendar {
   virtual void handleComputeFields(int32_t julianDay, UErrorCode &status) override;
 
   // UObject stuff
- public: 
+ public:
   /**
    * @return   The class ID for this object. All objects of a given class have the
    *           same class ID. Objects of other classes have different class IDs.

deps/openssl/openssl/CHANGES.md

@@ -12573,7 +12573,7 @@ OpenSSL 0.9.8.]
    *Steve Henson*
 
  * Reduced header interdependencies by declaring more opaque objects in
-   ossl_typ.h. As a consequence, including some headers (eg. engine.h) will
+   ossl_typ.h. As a consequence, including some headers (e.g. engine.h) will
    give fewer recursive includes, which could break lazy source code - so
    this change is covered by the OPENSSL_NO_DEPRECATED symbol. As always,
    developers should define this symbol when building and using openssl to
@@ -12926,7 +12926,7 @@ OpenSSL 0.9.8.]
    *Lutz Jaenicke*
 
  * Key-generation can now be implemented in RSA_METHOD, DSA_METHOD
-   and DH_METHOD (eg. by ENGINE implementations) to override the normal
+   and DH_METHOD (e.g. by ENGINE implementations) to override the normal
    software implementations. For DSA and DH, parameter generation can
    also be overridden by providing the appropriate method callbacks.
 
@@ -14584,7 +14584,7 @@ OpenSSL 0.9.7.]
 
  * As with "ERR", make it possible to replace the underlying "ex_data"
    functions. This change also alters the storage and management of global
-   ex_data state - it's now all inside ex_data.c and all "class" code (eg.
+   ex_data state - it's now all inside ex_data.c and all "class" code (e.g.
    RSA, BIO, SSL_CTX, etc) no longer stores its own STACKS and per-class
    index counters. The API functions that use this state have been changed
    to take a "class_index" rather than pointers to the class's local STACK
@@ -14922,7 +14922,7 @@ s-cbc           3624.96k     5258.21k     5530.91k     5624.30k     5628.26k
    that "executable" commands cannot return anything other than a boolean
    result and can only support numeric or string input, whereas some
    discoverable commands may only be for direct use through
-   ENGINE_ctrl(), eg. supporting the exchange of binary data, function
+   ENGINE_ctrl(), e.g. supporting the exchange of binary data, function
    pointers, or other custom uses. The "executable" commands are to
    support parameterisations of ENGINE behaviour that can be
    unambiguously defined by ENGINEs and used consistently across any

deps/openssl/openssl/README-ENGINES.md

@@ -53,7 +53,7 @@ user/admin the set of commands and parameter types a given ENGINE
 implementation supports, and for an application to directly feed string
 based input to those ENGINEs, in the form of name-value pairs. This is an
 extensible way for ENGINEs to define their own "configuration" mechanisms
-that are specific to a given ENGINE (eg. for a particular hardware
+that are specific to a given ENGINE (e.g. for a particular hardware
 device) but that should be consistent across *all* OpenSSL-based
 applications when they use that ENGINE. Work is in progress (or at least
 in planning) for supporting these control commands from the CONF (or
@@ -136,7 +136,7 @@ applications. This could be because existing compiled-in implementations
 have known problems and you wish to use a newer version with an existing
 application. It could equally be because the application (or OpenSSL
 library) you are using simply doesn't have support for the ENGINE you
-wish to use, and the ENGINE provider (eg. hardware vendor) is providing
+wish to use, and the ENGINE provider (e.g. hardware vendor) is providing
 you with a self-contained implementation in the form of a shared-library.
 The other use-case for "dynamic" is with applications that wish to
 maintain the smallest foot-print possible and so do not link in various
@@ -218,10 +218,10 @@ Applications that support the ENGINE API and more specifically, the
 such commands through to ENGINEs. As such, you would select "dynamic"
 as the ENGINE to use, and the parameters/commands you pass would
 control the *actual* ENGINE used. Each command is actually a name-value
-pair and the value can sometimes be omitted (eg. the "LOAD" command).
+pair and the value can sometimes be omitted (e.g. the "LOAD" command).
 Whilst the syntax demonstrated in "openssl engine" uses a colon to
 separate the command name from the value, applications may provide
-their own syntax for making that separation (eg. a win32 registry
+their own syntax for making that separation (e.g. a win32 registry
 key-value pair may be used by some applications). The reason for the
 "-pre" syntax in the "openssl engine" utility is that some commands
 might be issued to an ENGINE *after* it has been initialised for use.
@@ -285,7 +285,7 @@ ENGINE.
 
     - add "-DENGINE_DYNAMIC_SUPPORT" to the command line switches,
     - change the output file from "hw_atalla.o" to something new,
-      eg. "tmp_atalla.o"
+      e.g. "tmp_atalla.o"
 
 4.  Link "tmp_atalla.o" into a shared-library using the top-level
     OpenSSL libraries to resolve any dependencies. The syntax for doing

deps/openssl/openssl/apps/s_server.c

@@ -3805,7 +3805,7 @@ static int generate_session_id(SSL *ssl, unsigned char *id,
             return 0;
         /*
          * Prefix the session_id with the required prefix. NB: If our prefix
-         * is too long, clip it - but there will be worse effects anyway, eg.
+         * is too long, clip it - but there will be worse effects anyway, e.g.
          * the server could only possibly create 1 session ID (ie. the
          * prefix!) so all future session negotiations will fail due to
          * conflicts.

deps/openssl/openssl/crypto/engine/README.md

@@ -34,7 +34,7 @@ algorithm/mode pair are;
 
 The latter is more generally used because it also allows ciphers/digests to be
 looked up based on other identifiers which can be useful for automatic cipher
-selection, eg. in SSL/TLS, or by user-controllable configuration.
+selection, e.g. in SSL/TLS, or by user-controllable configuration.
 
 The important point about this is that EVP_CIPHER definitions and structures are
 passed around with impunity and there is no safe way, without requiring massive
@@ -62,7 +62,7 @@ they are available *because* they're part of a giant ENGINE called "openssl".
 Ie. all implementations *have* to come from an ENGINE, but we get round that by
 having a giant ENGINE with all the software support encapsulated. This creates
 linker hassles if nothing else - linking a 1-line application that calls 2 basic
-RSA functions (eg. "RSA_free(RSA_new());") will result in large quantities of
+RSA functions (e.g. "RSA_free(RSA_new());") will result in large quantities of
 ENGINE code being linked in *and* because of that DSA, DH, and RAND also. If we
 continue with this approach for EVP_CIPHER support (even if it *was* possible)
 we would lose our ability to link selectively by selectively loading certain
@@ -137,7 +137,7 @@ to a potentially NULL "ENGINE_PILE". An ENGINE_PILE is essentially a list of
 pointers to ENGINEs that implement that particular 'nid'. Each "pile" uses some
 caching tricks such that requests on that 'nid' will be cached and all future
 requests will return immediately (well, at least with minimal operation) unless
-a change is made to the pile, eg. perhaps an ENGINE was unloaded. The reason is
+a change is made to the pile, e.g. perhaps an ENGINE was unloaded. The reason is
 that an application could have support for 10 ENGINEs statically linked
 in, and the machine in question may not have any of the hardware those 10
 ENGINEs support. If each of those ENGINEs has a "des_cbc" implementation, we
@@ -187,7 +187,7 @@ registered an implementation, the code will simply return NULL and the tb_rsa.c
 state will be unchanged. Thus, no cleanup is required unless registration takes
 place. ENGINE_cleanup() will simply iterate across a list of registered cleanup
 callbacks calling each in turn, and will then internally delete its own storage
-(a STACK). When a cleanup callback is next registered (eg. if the cleanup() is
+(a STACK). When a cleanup callback is next registered (e.g. if the cleanup() is
 part of a graceful restart and the application wants to cleanup all state then
 start again), the internal STACK storage will be freshly allocated. This is much
 the same as the situation in the ENGINE_TABLE instantiations ... NULL is the

deps/openssl/openssl/crypto/engine/eng_ctrl.c

@@ -68,7 +68,7 @@ static int int_ctrl_helper(ENGINE *e, int cmd, long i, void *p,
     char *s = (char *)p;
     const ENGINE_CMD_DEFN *cdp;
 
-    /* Take care of the easy one first (eg. it requires no searches) */
+    /* Take care of the easy one first (e.g. it requires no searches) */
     if (cmd == ENGINE_CTRL_GET_FIRST_CMD_TYPE) {
         if ((e->cmd_defns == NULL) || int_ctrl_cmd_is_null(e->cmd_defns))
             return 0;

deps/openssl/openssl/crypto/engine/eng_dyn.c

@@ -268,7 +268,7 @@ void engine_load_dynamic_int(void)
     ENGINE_free(toadd);
     /*
      * If the "add" didn't work, it was probably a conflict because it was
-     * already added (eg. someone calling ENGINE_load_blah then calling
+     * already added (e.g. someone calling ENGINE_load_blah then calling
      * ENGINE_load_builtin_engines() perhaps).
      */
     ERR_pop_to_mark();

deps/openssl/openssl/crypto/engine/eng_lib.c

@@ -90,7 +90,7 @@ int engine_free_util(ENGINE *e, int not_locked)
     engine_pkey_asn1_meths_free(e);
     /*
      * Give the ENGINE a chance to do any structural cleanup corresponding to
-     * allocation it did in its constructor (eg. unload error strings)
+     * allocation it did in its constructor (e.g. unload error strings)
      */
     if (e->destroy)
         e->destroy(e);

deps/openssl/openssl/crypto/engine/eng_openssl.c

@@ -160,7 +160,7 @@ void engine_load_openssl_int(void)
     ENGINE_free(toadd);
     /*
      * If the "add" didn't work, it was probably a conflict because it was
-     * already added (eg. someone calling ENGINE_load_blah then calling
+     * already added (e.g. someone calling ENGINE_load_blah then calling
      * ENGINE_load_builtin_engines() perhaps).
      */
     ERR_pop_to_mark();

deps/openssl/openssl/crypto/engine/eng_rdrand.c

@@ -112,7 +112,7 @@ void engine_load_rdrand_int(void)
         ENGINE_free(toadd);
         /*
         * If the "add" didn't work, it was probably a conflict because it was
-        * already added (eg. someone calling ENGINE_load_blah then calling
+        * already added (e.g. someone calling ENGINE_load_blah then calling
         * ENGINE_load_builtin_engines() perhaps).
         */
         ERR_pop_to_mark();