linux-kernel - Re: [PATCH 1/1] Fix typos in Documentation/unaligned-memory-access.txt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <47ED5BF5.4000809@oracle.com>
Date:	Fri, 28 Mar 2008 13:58:29 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Dmitri Vorobiev <dmitri.vorobiev@...il.com>
CC:	Sebastien Dugue <sebastien.dugue@...l.net>, dsd@...too.org,
	trivial@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] Fix typos in Documentation/unaligned-memory-access.txt

Dmitri Vorobiev wrote:
> Sebastien Dugue wrote:
>>   Hi Dmitri,
>>
>>   one more typo I guess:
>>
>> On Fri, 28 Mar 2008 13:10:42 +0300 Dmitri Vorobiev <dmitri.vorobiev@...il.com> wrote:
>>
>>> This patch deletes a couple of superfluous word occurrences in the
>>> document Documentation/unaligned-memory-access.txt.
>>> ---
>>> Sorry for a duplicate email, I forgot to Cc LKML when sending the patch.
>>>
>>>  Documentation/unaligned-memory-access.txt |    4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt
>>> index 6223eac..ed57b53 100644
>>> --- a/Documentation/unaligned-memory-access.txt
>>> +++ b/Documentation/unaligned-memory-access.txt
>>> @@ -57,7 +57,7 @@ here; a summary of the common scenarios is presented below:
>>>     unaligned access to be corrected.
>>>   - Some architectures are not capable of unaligned memory access, but will
>>>     silently perform a different memory access to the one that was requested,
>>> -   resulting a a subtle code bug that is hard to detect!
>>> +   resulting a subtle code bug that is hard to detect!
>>                 ^
>>                in a
> 
> Although those English dictionaries that I have consulted do indicate that
> "result" is an intransitive verb, there are many occurrences reported by Google
> when this verb takes a direct object like in the following phrase: "However,
> inner space of the stand 2 of the drum washing machine 1 is not used,
> resulting a problem of wasting space."
> 
> English is not my mother tongue so I can't claim I have a good ear for the
> language. Are there any native speakers who could help, please?

I'll ack the "in a" change.

> Dmitri
> 
>>   Sebastien.
>>
>>>  
>>>  It should be obvious from the above that if your code causes unaligned
>>>  memory accesses to happen, your code will not work correctly on certain
>>> @@ -209,7 +209,7 @@ memory and you wish to avoid unaligned access, its usage is as follows:
>>>  
>>>  	u32 value = get_unaligned((u32 *) data);
>>>  
>>> -These macros work work for memory accesses of any length (not just 32 bits as
>>> +These macros work for memory accesses of any length (not just 32 bits as
>>>  in the examples above). Be aware that when compared to standard access of
>>>  aligned memory, using these macros to access unaligned memory can be costly in
>>>  terms of performance.
> 


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/