diff mbox

Fixing some spelling in docs/libcacard.txt

Message ID 1321358234-14229-1-git-send-email-matthias.bgg@gmail.com
State New
Headers show

Commit Message

matthias.bgg@googlemail.com Nov. 15, 2011, 11:57 a.m. UTC
From: Matthias Brugger <matthias.bgg@gmail.com>


Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
 docs/libcacard.txt |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

Comments

Alon Levy Nov. 15, 2011, 11:24 a.m. UTC | #1
On Tue, Nov 15, 2011 at 11:57:14AM +0000, matthias.bgg@googlemail.com wrote:
> From: Matthias Brugger <matthias.bgg@gmail.com>
> 

Thanks!

Reviewed-by: Alon Levy <alevy@redhat.com>

> 
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
>  docs/libcacard.txt |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/libcacard.txt b/docs/libcacard.txt
> index 5dee6fa..576af57 100644
> --- a/docs/libcacard.txt
> +++ b/docs/libcacard.txt
> @@ -170,7 +170,7 @@ public entry point:
>                                 int cert_count);
>  
>    The parameters for this are:
> -  card       - the virtual card structure which will prepresent this card.
> +  card       - the virtual card structure which will represent this card.
>    flags      - option flags that may be specific to this card type.
>    cert       - array of binary certificates.
>    cert_len   - array of lengths of each of the certificates specified in cert.
> @@ -179,7 +179,7 @@ public entry point:
>    cert_count - number of entries in cert, cert_len, and key arrays.
>  
>    Any cert, cert_len, or key with the same index are matching sets. That is
> -  cert[0] is cert_len[0] long and has the corresponsing private key of key[0].
> +  cert[0] is cert_len[0] long and has the corresponding private key of key[0].
>  
>  The card type emulator is expected to own the VCardKeys, but it should copy
>  any raw cert data it wants to save. It can create new applets and add them to
> @@ -261,7 +261,7 @@ Prior to processing calling the card type emulator's VCardProcessAPDU function,
>     apdu->a_Le   - The expected length of any returned data.
>     apdu->a_cla  - The raw apdu class.
>     apdu->a_channel - The channel (decoded from the class).
> -   apdu->a_secure_messaging_type - The decoded secure messagin type
> +   apdu->a_secure_messaging_type - The decoded secure messaging type
>                                     (from class).
>     apdu->a_type - The decode class type.
>     apdu->a_gen_type - the generic class type (7816, PROPRIETARY, RFU, PTS).
> @@ -273,7 +273,7 @@ Creating a Response --
>  
>  The expected result of any APDU call is a response. The card type emulator must
>  set *response with an appropriate VCardResponse value if it returns VCARD_DONE.
> -Reponses could be as simple as returning a 2 byte status word response, to as
> +Responses could be as simple as returning a 2 byte status word response, to as
>  complex as returning a block of data along with a 2 byte response. Which is
>  returned will depend on the semantics of the APDU. The following functions will
>  create card responses.
> @@ -282,12 +282,12 @@ create card responses.
>  
>      This is the most basic function to get a response. This function will
>      return a response the consists soley one 2 byte status code. If that status
> -    code is defined in card_7816t.h, then this function is guarrenteed to
> +    code is defined in card_7816t.h, then this function is guaranteed to
>      return a response with that status. If a cart type specific status code
>      is passed and vcard_make_response fails to allocate the appropriate memory
>      for that response, then vcard_make_response will return a VCardResponse
>      of VCARD7816_STATUS_EXC_ERROR_MEMORY. In any case, this function is
> -    guarrenteed to return a valid VCardResponse.
> +    guaranteed to return a valid VCardResponse.
>  
>          VCardResponse *vcard_response_new(unsigned char *buf, int len,
>                                            VCard7816Status status);
> -- 
> 1.7.1
> 
>
Stefan Hajnoczi Nov. 18, 2011, 11:24 a.m. UTC | #2
On Tue, Nov 15, 2011 at 11:57:14AM +0000, matthias.bgg@googlemail.com wrote:
> From: Matthias Brugger <matthias.bgg@gmail.com>
> 
> 
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
>  docs/libcacard.txt |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

I have already sent a pull request including this patch for QEMU 1.0.

Stefan
diff mbox

Patch

diff --git a/docs/libcacard.txt b/docs/libcacard.txt
index 5dee6fa..576af57 100644
--- a/docs/libcacard.txt
+++ b/docs/libcacard.txt
@@ -170,7 +170,7 @@  public entry point:
                                int cert_count);
 
   The parameters for this are:
-  card       - the virtual card structure which will prepresent this card.
+  card       - the virtual card structure which will represent this card.
   flags      - option flags that may be specific to this card type.
   cert       - array of binary certificates.
   cert_len   - array of lengths of each of the certificates specified in cert.
@@ -179,7 +179,7 @@  public entry point:
   cert_count - number of entries in cert, cert_len, and key arrays.
 
   Any cert, cert_len, or key with the same index are matching sets. That is
-  cert[0] is cert_len[0] long and has the corresponsing private key of key[0].
+  cert[0] is cert_len[0] long and has the corresponding private key of key[0].
 
 The card type emulator is expected to own the VCardKeys, but it should copy
 any raw cert data it wants to save. It can create new applets and add them to
@@ -261,7 +261,7 @@  Prior to processing calling the card type emulator's VCardProcessAPDU function,
    apdu->a_Le   - The expected length of any returned data.
    apdu->a_cla  - The raw apdu class.
    apdu->a_channel - The channel (decoded from the class).
-   apdu->a_secure_messaging_type - The decoded secure messagin type
+   apdu->a_secure_messaging_type - The decoded secure messaging type
                                    (from class).
    apdu->a_type - The decode class type.
    apdu->a_gen_type - the generic class type (7816, PROPRIETARY, RFU, PTS).
@@ -273,7 +273,7 @@  Creating a Response --
 
 The expected result of any APDU call is a response. The card type emulator must
 set *response with an appropriate VCardResponse value if it returns VCARD_DONE.
-Reponses could be as simple as returning a 2 byte status word response, to as
+Responses could be as simple as returning a 2 byte status word response, to as
 complex as returning a block of data along with a 2 byte response. Which is
 returned will depend on the semantics of the APDU. The following functions will
 create card responses.
@@ -282,12 +282,12 @@  create card responses.
 
     This is the most basic function to get a response. This function will
     return a response the consists soley one 2 byte status code. If that status
-    code is defined in card_7816t.h, then this function is guarrenteed to
+    code is defined in card_7816t.h, then this function is guaranteed to
     return a response with that status. If a cart type specific status code
     is passed and vcard_make_response fails to allocate the appropriate memory
     for that response, then vcard_make_response will return a VCardResponse
     of VCARD7816_STATUS_EXC_ERROR_MEMORY. In any case, this function is
-    guarrenteed to return a valid VCardResponse.
+    guaranteed to return a valid VCardResponse.
 
         VCardResponse *vcard_response_new(unsigned char *buf, int len,
                                           VCard7816Status status);