fix some typos

Signed-off-by: cui fliter <[email protected]>

build_odin.sh

@@ -32,7 +32,7 @@ config_darwin() {
 	if [ ARCH == arm64 ]; then
 		MIN_LLVM_VERSION=("13.0.0")
 	else
-		# allow for x86 / amd64 all llvm versions begining from 11
+		# allow for x86 / amd64 all llvm versions beginning from 11
 		MIN_LLVM_VERSION=("11.1.0")
 	fi
 

core/bufio/scanner.odin

@@ -66,7 +66,7 @@ scanner_destroy :: proc(s: ^Scanner) {
 }
 
 
-// Returns the first non-EOF error that was encounted by the scanner
+// Returns the first non-EOF error that was encountered by the scanner
 scanner_error :: proc(s: ^Scanner) -> Scanner_Error {
 	switch s._err {
 	case .EOF, nil:

core/c/libc/math.odin

@@ -331,7 +331,7 @@ fmin       :: proc{libc_fmin, libc_fminf}
 fma        :: proc{libc_fma, libc_fmaf}
 
 // But retain the 'f' suffix-variant functions as well so they can be used,
-// a trick is used here where we use explicit procedrual overloading of one
+// a trick is used here where we use explicit procedural overloading of one
 // procedure. This is done because the foreign block is marked @(private) and
 // aliasing functions does not remove privateness from the entity.
 acosf      :: proc{libc_acosf}

core/crypto/README.md

@@ -81,7 +81,7 @@ The crypto package is not thread-safe at the moment. This may change in the futu
 ### Disclaimer
 The algorithms were ported out of curiosity and due to interest in the field.
 We have not had any of the code verified by a third party or tested/fuzzed by any automatic means.
-Whereever we were able to find official test vectors, those were used to verify the implementation.
+Wherever we were able to find official test vectors, those were used to verify the implementation.
 We do not recommend using them in a production environment, without any additional testing and/or verification.
 
 ### ToDo

core/crypto/_fiat/README.md

@@ -30,6 +30,6 @@ equivalence.
 
 For the most part, alterations to the base fiat-crypto generated code was
 kept to a minimum, to aid auditability.  This results in a somewhat
-ideosyncratic style, and in some cases minor performance penalties.
+idiosyncratic style, and in some cases minor performance penalties.
 
 [1]: https://github.com/mit-plv/fiat-crypto

core/crypto/siphash/siphash.odin

@@ -233,7 +233,7 @@ init :: proc(ctx: ^Context, key: []byte, c_rounds, d_rounds: int) {
 }
 
 update :: proc(ctx: ^Context, data: []byte) {
-    assert(ctx.is_initialized, "crypto/siphash: Context is not initalized")
+    assert(ctx.is_initialized, "crypto/siphash: Context is not initialized")
     ctx.last_block = len(data) / 8 * 8
     ctx.buf = data
     i := 0

core/encoding/hxa/hxa.odin

@@ -107,7 +107,7 @@ Node :: struct {
 /* Conventions */
 /* ------------
 Much of HxA's use is based on convention. HxA lets users store arbitrary data in its structure that can be parsed but whose semantic meaning does not need to be understood.
-A few conventions are hard, and some are soft. Hard convention that a user HAS to follow in order to produce a valid file. Hard conventions simplify parsing becaus the parser can make some assumptions. Soft convenbtions are basicly recomendations of how to store common data.
+A few conventions are hard, and some are soft. Hard convention that a user HAS to follow in order to produce a valid file. Hard conventions simplify parsing becaus the parser can make some assumptions. Soft convenbtions are basically recomendations of how to store common data.
 If you use HxA for something not covered by the conventions but need a convention for your use case. Please let us know so that we can add it!
 */
 

core/image/common.odin

@@ -469,7 +469,7 @@ return_single_channel :: proc(img: ^Image, channel: Channel) -> (res: ^Image, ok
 }
 
 // Does the image have 1 or 2 channels, a valid bit depth (8 or 16),
-// Is the pointer valid, are the dimenions valid?
+// Is the pointer valid, are the dimensions valid?
 is_valid_grayscale_image :: proc(img: ^Image) -> (ok: bool) {
 	// Were we actually given a valid image?
 	if img == nil {
@@ -489,7 +489,7 @@ is_valid_grayscale_image :: proc(img: ^Image) -> (ok: bool) {
 	// This returns 0 if any of the inputs is zero.
 	bytes_expected := compute_buffer_size(img.width, img.height, img.channels, img.depth)
 
-	// If the dimenions are invalid or the buffer size doesn't match the image characteristics, bail.
+	// If the dimensions are invalid or the buffer size doesn't match the image characteristics, bail.
 	if bytes_expected == 0 || bytes_expected != len(img.pixels.buf) || img.width * img.height > MAX_DIMENSIONS {
 		return false
 	}
@@ -498,7 +498,7 @@ is_valid_grayscale_image :: proc(img: ^Image) -> (ok: bool) {
 }
 
 // Does the image have 3 or 4 channels, a valid bit depth (8 or 16),
-// Is the pointer valid, are the dimenions valid?
+// Is the pointer valid, are the dimensions valid?
 is_valid_color_image :: proc(img: ^Image) -> (ok: bool) {
 	// Were we actually given a valid image?
 	if img == nil {
@@ -518,7 +518,7 @@ is_valid_color_image :: proc(img: ^Image) -> (ok: bool) {
 	// This returns 0 if any of the inputs is zero.
 	bytes_expected := compute_buffer_size(img.width, img.height, img.channels, img.depth)
 
-	// If the dimenions are invalid or the buffer size doesn't match the image characteristics, bail.
+	// If the dimensions are invalid or the buffer size doesn't match the image characteristics, bail.
 	if bytes_expected == 0 || bytes_expected != len(img.pixels.buf) || img.width * img.height > MAX_DIMENSIONS {
 		return false
 	}
@@ -527,7 +527,7 @@ is_valid_color_image :: proc(img: ^Image) -> (ok: bool) {
 }
 
 // Does the image have 1..4 channels, a valid bit depth (8 or 16),
-// Is the pointer valid, are the dimenions valid?
+// Is the pointer valid, are the dimensions valid?
 is_valid_image :: proc(img: ^Image) -> (ok: bool) {
 	// Were we actually given a valid image?
 	if img == nil {

core/math/big/prime.odin

@@ -449,7 +449,7 @@ internal_int_is_prime :: proc(a: ^Int, miller_rabin_trials := int(-1), miller_ra
 			in the loop is non-zero, although very low.
 			-- NOTE(Jeroen): This is not yet true in Odin, but I have some ideas.
 
-			If the BPSW test and/or the addtional Frobenious test have been
+			If the BPSW test and/or the additional Frobenious test have been
 			performed instead of just the Miller-Rabin test with the bases 2 and 3,
 			a single extra test should suffice, so such a very unlikely event will not do much harm.