fixing two typos; incomplete error message; exit status
Benno Schulenberg <[email protected]> Wed, 23 Oct 2019 11:34:11 +0200
| Newsgroups | gmane.comp.gnu.aspell.devel |
|---|---|
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fdnfz38AkGARsrV7IyBc311iZU0F4gSY7 Content-Type: multipart/mixed; boundary="M9VEZhWmjXm7JXiphjUFlINPkNrL58o9Z"; protected-headers="v1" From: Benno Schulenberg <[email protected]> To: [email protected] Message-ID: <[email protected]> Subject: fixing two typos; incomplete error message; exit status --M9VEZhWmjXm7JXiphjUFlINPkNrL58o9Z Content-Type: multipart/mixed; boundary="------------ADD52ECCCF20E5C3B9CE9E09" Content-Language: en-US This is a multi-part message in MIME format. --------------ADD52ECCCF20E5C3B9CE9E09 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Kevin, Looking through the documentation of 0.60.8 for some info about the exit status of aspell, I came across a typo ("termianted") in the README file. Then I spell-checked the whole thing and found another ("implemenation"). Attached patch fixes those. Then something I've wanted to report since a long time: most tools allow one to bundle the short options, but aspell doesn't. When one tries to run 'aspell -xc somefile' it not only fails, it also says: Error: does not take any parameters. Something appears to be missing ("-x"?) from the message. So, it would be good if the manual said that short options may not be concatenated. And it would be nice if the manual said something about the exit status of aspell. That it is zero when no error occurred. Whether spelling corrections were made or not cannot be seen in the exit status. (On http://aspell.net/ there's a typo too: s/slower/slowly/.) Benno --------------ADD52ECCCF20E5C3B9CE9E09 Content-Type: text/x-patch; name="0001-docs-fix-two-typos.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-docs-fix-two-typos.patch" =46rom 4c5f97b20d22299e9c37c8c07f16a792f86d2ac8 Mon Sep 17 00:00:00 2001 From: Benno Schulenberg <[email protected]> Date: Wed, 23 Oct 2019 11:02:18 +0200 Subject: [PATCH] docs: fix two typos --- manual/readme.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/manual/readme.texi b/manual/readme.texi index fdd4eb2..6dd0e34 100644 --- a/manual/readme.texi +++ b/manual/readme.texi @@ -157,7 +157,7 @@ Error: The file ``@var{some-file}'' is not in the pro= per format. Incompatible ha =20 To prevent a potentially unbounded buffer over-read, Aspell no longer supports null-terminated UCS-2 and UCS-4 encoded strings with the -original C API. Null-termianted 8-bit or UTF-8 encoded strings are +original C API. Null-terminated 8-bit or UTF-8 encoded strings are still supported, as are UCS-2 and UCS-4 encoded strings when the length is passed in. =20 @@ -184,7 +184,7 @@ could result in an unbounded buffer over-read. If it is necessary to preserve binary compatibility with older versions of Aspell, the easiest thing would be to determine the length of the UCS-2/4 string---in bytes---and pass that in. Due to an -implemenation detail, existing API functions can be made to work with +implementation detail, existing API functions can be made to work with null-terminated UCS-2/4 strings safely by passing in either @code{-2} or @code{-4} (corresponding to the width of the character type) as the size. Doing so, however, will cause a buffer over-read for unpatched --=20 2.23.0 --------------ADD52ECCCF20E5C3B9CE9E09-- --M9VEZhWmjXm7JXiphjUFlINPkNrL58o9Z-- --fdnfz38AkGARsrV7IyBc311iZU0F4gSY7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEv9AJBh5TUFKtDfIVDSjU0qCs6IQFAl2wHpsACgkQDSjU0qCs 6ITdBA//TMsY3VNQAAN3+BroEbQlpYn8PmjOQpDhPeIQuzFI/AyljM+xGXH/SD4q 3tyiLBmB6zq6UXbDFKhECWbUhFk1PfPD23j0loYvAskPhoYDKO81AEojZcSxdDSs 0eTMUKpFn2uskjw/mh7yYAk0ulBqc/WYFlhhRGavIYMc/H85kxkyFd+LZTEnH5Pe Ez//gakw2U3mlhO1+EKzBbuMTarrdA7uEdix4zhcfGIjiwPfKRk5b6PajH2L+D71 Q/ZTwIIVeLZOhPy3aZlcO7O72B3wSEQjqMPd4Vt+DiAwBmj15Y2q3QrKdBaowhd3 9Porq1KzyBcDPj2e/sUNIbl5B5qHdUr9z8k/bIWXyL1Pz1YIuXvewmsu6PXFztmR CfAHMSdPPkLbna526U1PV72bMJdlzyefAg/NArudFb880c40mAh4lmAjldr9wBUp IWPtsAy2AmRXq+m7FYEHkwOaPH6dX1CDRKlCgEUvOGj6SZl3buQ+sm3o8QMKEvhL R/NFqLM1Kh2ZSr6EgcNWlks6X24AwjoYaWfQQ6IW2GQi6ehZHEmWtWbFsc7ID+95 g0eauaL1CFAwKwstCe5NMl09KaMiN5zGwqoTH9gIwirv0Eyuk2V+J/UCeX6wxIbG 3glPpH9Pk0ECW1TKxzftZZTj/b5Qa1YUwbUt0L+lZnfmuKBgdiA= =fgZN -----END PGP SIGNATURE----- --fdnfz38AkGARsrV7IyBc311iZU0F4gSY7--