Re: [PATCH] Spelling fixes for libcrypto
On Fri, Jan 06, 2023 at 11:39:03PM -0600, Purple Rain wrote:
> Hi, everyone! Some spelling fixes for libcrypto.
>
> I added a diff for revision.
Thanks. You can't just change the name of a constant in a public header.
Some code out there might use it and no longer compile after we commit
your diff. For example, Python uses the error codes internally.
OpenSSL fixed this spelling error in 1.1:
https://github.com/openssl/openssl/pull/1421
It turns out that Python uses the version without typo behind an #ifdef.
The safe way to fix this typo is to keep a compat #define
/* Changed in OpenSSL 1.1 */
#define EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS
in evp.h. We should probably do this.
>
> P.
>
> Index: lib/libcrypto/evp/evp.h
> ===
> RCS file: /cvs/src/lib/libcrypto/evp/evp.h,v
> retrieving revision 1.112
> diff -u -p -r1.112 evp.h
> --- lib/libcrypto/evp/evp.h 13 Nov 2022 14:04:13 - 1.112
> +++ lib/libcrypto/evp/evp.h 7 Jan 2023 03:28:26 -
> @@ -1467,7 +1467,7 @@ void ERR_load_EVP_strings(void);
> #define EVP_R_UNKNOWN_DIGEST 161
> #define EVP_R_UNKNOWN_OPTION 169
> #define EVP_R_UNKNOWN_PBE_ALGORITHM 121
> -#define EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS 135
> +#define EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS135
> #define EVP_R_UNSUPPORTED_ALGORITHM 156
> #define EVP_R_UNSUPPORTED_CIPHER 107
> #define EVP_R_UNSUPPORTED_KEYLENGTH 123
> Index: lib/libcrypto/evp/evp_err.c
> ===
> RCS file: /cvs/src/lib/libcrypto/evp/evp_err.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 evp_err.c
> --- lib/libcrypto/evp/evp_err.c 10 Nov 2022 15:17:30 - 1.30
> +++ lib/libcrypto/evp/evp_err.c 7 Jan 2023 03:28:26 -
> @@ -137,7 +137,7 @@ static ERR_STRING_DATA EVP_str_reasons[]
> {ERR_REASON(EVP_R_UNKNOWN_DIGEST), "unknown digest"},
> {ERR_REASON(EVP_R_UNKNOWN_OPTION), "unknown option"},
> {ERR_REASON(EVP_R_UNKNOWN_PBE_ALGORITHM) , "unknown pbe algorithm"},
> - {ERR_REASON(EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS), "unsuported number of
> rounds"},
> + {ERR_REASON(EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS), "unsupported number of
> rounds"},
> {ERR_REASON(EVP_R_UNSUPPORTED_ALGORITHM) , "unsupported algorithm"},
> {ERR_REASON(EVP_R_UNSUPPORTED_CIPHER), "unsupported cipher"},
> {ERR_REASON(EVP_R_UNSUPPORTED_KEYLENGTH) , "unsupported keylength"},
> Index: lib/libcrypto/evp/p5_crpt.c
> ===
> RCS file: /cvs/src/lib/libcrypto/evp/p5_crpt.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 p5_crpt.c
> --- lib/libcrypto/evp/p5_crpt.c 26 Nov 2022 16:08:52 - 1.21
> +++ lib/libcrypto/evp/p5_crpt.c 7 Jan 2023 03:28:26 -
> @@ -109,7 +109,7 @@ PKCS5_PBE_keyivgen(EVP_CIPHER_CTX *cctx,
> if (!pbe->iter)
> iter = 1;
> else if ((iter = ASN1_INTEGER_get(pbe->iter)) <= 0) {
> - EVPerror(EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS);
> + EVPerror(EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS);
> PBEPARAM_free(pbe);
> return 0;
> }
> Index: lib/libcrypto/evp/p5_crpt2.c
> ===
> RCS file: /cvs/src/lib/libcrypto/evp/p5_crpt2.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 p5_crpt2.c
> --- lib/libcrypto/evp/p5_crpt2.c 26 Nov 2022 16:08:52 - 1.25
> +++ lib/libcrypto/evp/p5_crpt2.c 7 Jan 2023 03:28:26 -
> @@ -290,7 +290,7 @@ PKCS5_v2_PBKDF2_keyivgen(EVP_CIPHER_CTX
> salt = kdf->salt->value.octet_string->data;
> saltlen = kdf->salt->value.octet_string->length;
> if ((iter = ASN1_INTEGER_get(kdf->iter)) <= 0) {
> - EVPerror(EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS);
> + EVPerror(EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS);
> goto err;
> }
> if (!PKCS5_PBKDF2_HMAC(pass, passlen, salt, saltlen, iter, prfmd,
>
[PATCH] Spelling fixes for libcrypto
Hi, everyone! Some spelling fixes for libcrypto.
I added a diff for revision.
P.
Index: lib/libcrypto/evp/evp.h
===
RCS file: /cvs/src/lib/libcrypto/evp/evp.h,v
retrieving revision 1.112
diff -u -p -r1.112 evp.h
--- lib/libcrypto/evp/evp.h 13 Nov 2022 14:04:13 - 1.112
+++ lib/libcrypto/evp/evp.h 7 Jan 2023 03:28:26 -
@@ -1467,7 +1467,7 @@ void ERR_load_EVP_strings(void);
#define EVP_R_UNKNOWN_DIGEST161
#define EVP_R_UNKNOWN_OPTION169
#define EVP_R_UNKNOWN_PBE_ALGORITHM 121
-#define EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS 135
+#define EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS 135
#define EVP_R_UNSUPPORTED_ALGORITHM 156
#define EVP_R_UNSUPPORTED_CIPHER107
#define EVP_R_UNSUPPORTED_KEYLENGTH 123
Index: lib/libcrypto/evp/evp_err.c
===
RCS file: /cvs/src/lib/libcrypto/evp/evp_err.c,v
retrieving revision 1.30
diff -u -p -r1.30 evp_err.c
--- lib/libcrypto/evp/evp_err.c 10 Nov 2022 15:17:30 - 1.30
+++ lib/libcrypto/evp/evp_err.c 7 Jan 2023 03:28:26 -
@@ -137,7 +137,7 @@ static ERR_STRING_DATA EVP_str_reasons[]
{ERR_REASON(EVP_R_UNKNOWN_DIGEST), "unknown digest"},
{ERR_REASON(EVP_R_UNKNOWN_OPTION), "unknown option"},
{ERR_REASON(EVP_R_UNKNOWN_PBE_ALGORITHM) , "unknown pbe algorithm"},
- {ERR_REASON(EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS), "unsuported number of
rounds"},
+ {ERR_REASON(EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS), "unsupported number of
rounds"},
{ERR_REASON(EVP_R_UNSUPPORTED_ALGORITHM) , "unsupported algorithm"},
{ERR_REASON(EVP_R_UNSUPPORTED_CIPHER), "unsupported cipher"},
{ERR_REASON(EVP_R_UNSUPPORTED_KEYLENGTH) , "unsupported keylength"},
Index: lib/libcrypto/evp/p5_crpt.c
===
RCS file: /cvs/src/lib/libcrypto/evp/p5_crpt.c,v
retrieving revision 1.21
diff -u -p -r1.21 p5_crpt.c
--- lib/libcrypto/evp/p5_crpt.c 26 Nov 2022 16:08:52 - 1.21
+++ lib/libcrypto/evp/p5_crpt.c 7 Jan 2023 03:28:26 -
@@ -109,7 +109,7 @@ PKCS5_PBE_keyivgen(EVP_CIPHER_CTX *cctx,
if (!pbe->iter)
iter = 1;
else if ((iter = ASN1_INTEGER_get(pbe->iter)) <= 0) {
- EVPerror(EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS);
+ EVPerror(EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS);
PBEPARAM_free(pbe);
return 0;
}
Index: lib/libcrypto/evp/p5_crpt2.c
===
RCS file: /cvs/src/lib/libcrypto/evp/p5_crpt2.c,v
retrieving revision 1.25
diff -u -p -r1.25 p5_crpt2.c
--- lib/libcrypto/evp/p5_crpt2.c26 Nov 2022 16:08:52 - 1.25
+++ lib/libcrypto/evp/p5_crpt2.c7 Jan 2023 03:28:26 -
@@ -290,7 +290,7 @@ PKCS5_v2_PBKDF2_keyivgen(EVP_CIPHER_CTX
salt = kdf->salt->value.octet_string->data;
saltlen = kdf->salt->value.octet_string->length;
if ((iter = ASN1_INTEGER_get(kdf->iter)) <= 0) {
- EVPerror(EVP_R_UNSUPORTED_NUMBER_OF_ROUNDS);
+ EVPerror(EVP_R_UNSUPPORTED_NUMBER_OF_ROUNDS);
goto err;
}
if (!PKCS5_PBKDF2_HMAC(pass, passlen, salt, saltlen, iter, prfmd,
ifconfig.c - redundancy
lines 1911 - 1913 and 1917 - 1919 are code blocks that are looking identical. I cannot imagine that that is on purpose. What do you really wanna express here?
Re: Making wscons a bit more like xterm
On Fri, Jan 06, 2023 at 06:21:41PM +, Nicholas Marriott wrote: > You should strictly only discard the following two arguments or stuff like > SGR 38;5;100;1 won't work. Well I was initially in two minds about that, because I thought there might be other un-official extensions that used 38 with a varying number of parameters. But I haven't found any apart from 5 followed by one argument, and 2 followed by three RGB values, so yes I agree with you on this. However, since this morning I've been working on actually implementing 256 colour support so the next version of the patch will parse SGR 38;5 sequences correctly. Presumably though, if we see SGR 38;X where X is neither 2 nor 5, we still have to discard everything, right? Because that would be an invalid sequence and we don't know for sure whether anything that comes after it is actually intended as regular control codes or parameters for something else. I.E. SGR 38;5;X - we set colour X. SGR 38;2;X;X;X - we discard three parameters, then continue parsing. SGR 38;Y; - where Y is 'something else', we ignore everything until the 'm'. Or is there a better way? Regarding 256 colour support, I've got it working, (on 32bpp displays only), but there are two open questions: 1. On displays that don't support 256 colours, (e.g. VGA console), what should SGR 38;5;X do? I currently have it set so that it selects colours 0-7, and for 8-255 just does nothing, (leaves the current colour). 2. We implement bold as brighter text rather than a bold font. This doesn't work very well with a 256 colour palette. We can't just +8 to get a bright version of the colour. How should bold work with arbitrary colours? > This is why some people prefer the : form but the ship has rather sailed on > that. I'm assuming that we don't really need to implement the : form? Thanks again for the feedback.
Re: Making wscons a bit more like xterm
You should strictly only discard the following two arguments or stuff like
SGR 38;5;100;1 won't work.
This is why some people prefer the : form but the ship has rather sailed on
that.
On Fri, 6 Jan 2023, 11:52 Crystal Kolipe,
wrote:
> This version of the patchset updates a few things since the one posted
> early
> on Wednesday:
>
> NEW - Fix two off-by-ones that caused spurious trailing null characters
> when
> requesting the terminal IDs. (Noticed by Paul running tmux.)
>
> NEW - Discard any parameters passed to a CSI 38 m or CSI 48 m sequence.
> See below for more discussion on this.
>
> NEW - Tweaked dim attribute to work correctly on byte-swapped framebuffers.
>
> * Control sequences for dim text, invisible text, strike through, italic,
> and
> double underline attributes are now recognised and set flags in wscons.
> * Rendering of dim, invisible, struck, and double underlined text is now
> supported in rasops32.c, so users of 32bpp displays will see these text
> effects on the console.
> * The default number of scrollback screens has been increased from five to
> twenty.
> * F1 - F4 and F13 - F24 now send different sequences.
> * With numlock OFF, keypad 5 is now 'begin' rather than unused.
> * Home, End, keypad home, and keypad end now send different sequences.
> * A new keysym has been added - KS_Backtab.
> * Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
> * Shift-F1 - Shift-F12 now send F13 - F24.
> * Five new escape sequences added for cursor movement.
>
> Off by ones:
>
> These can actually be triggered with the existing console code, without
> even
> applying any of my patches, and stem from using sizeof with a string
> constant,
> which returns the length of the string _including_ the terminating null.
>
> CSI 38 m and CSI 48 m sequences:
>
> The 30-37 codes set one of eight fixed foreground colours, the 40-47 codes
> set
> the background in the same way. Codes 39 and 49 reset to the default
> colours.
>
> Codes 38 and 48 have become used as an escape to a larger colour space,
> typically 256 colours or 24-bit colour.
>
> A typical invocation to select colour 100 from a 256 colour palette might
> be:
>
> CSI 38;5;100m
>
> Such sequences are not defined in the terminfo entry for xterm. However,
> some
> programs use them, assuming that they are supported.
>
> The current wscons code ignores the unimplemented 38, but then proceeds to
> interpret 5 and 100 as further SGR codes.
>
> In many cases, this doesn't much of a problem, because although 5 enables
> blink, none of the rasops code supports blink anyway. However, the last
> value
> can potentially set any SGR attribute. So, for example:
>
> CSI 38;5;4m
>
> ...will not select colour 4 as the program is expecting, but instead turn
> on
> underlining.
>
> To avoid this, the lastest version of my patch simply discards all values
> after a 38 or 48, until the trailing 'm'.
>
> This works to avoid setting unwanted attributes, until such time as 256
> colour
> support is added, (if this is even desired).
>
> --- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
> +++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
> @@ -37,11 +37,9 @@
> #include
> #include
>
> +#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
> +
> static const u_char *vt100_fkeys[] = {
> - "\033[11~", /* F1 */
> - "\033[12~",
> - "\033[13~", /* F1-F5 normally don't send codes */
> - "\033[14~",
> "\033[15~", /* F5 */
> "\033[17~", /* F6 */
> "\033[18~",
> @@ -50,18 +48,18 @@
> "\033[21~",
> "\033[23~", /* VT100: ESC */
> "\033[24~", /* VT100: BS */
> - "\033[25~", /* VT100: LF */
> - "\033[26~",
> - "\033[28~", /* help */
> - "\033[29~", /* do */
> - "\033[31~",
> - "\033[32~",
> - "\033[33~",
> - "\033[34~", /* F20 */
> - "\033[35~",
> - "\033[36~",
> - "\033[37~",
> - "\033[38~"
> + "\033[1;2P",/* VT100: LF */
> + "\033[1;2Q",
> + "\033[1;2R",/* help */
> + "\033[1;2S",/* do */
> + "\033[15;2~",
> + "\033[17;2~",
> + "\033[18;2~",
> + "\033[19;2~", /* F20 */
> + "\033[20;2~",
> + "\033[21;2~",
> + "\033[23;2~",
> + "\033[24;2~"
> };
>
> static const u_char *vt100_pfkeys[] = {
> @@ -96,14 +94,22 @@
> edp->translatebuf, edp->flags & VTFL_UTF8));
> }
>
> - if (in >= KS_f1 && in <= KS_f24) {
> - *out = vt100_fkeys[in - KS_f1];
> - return (5);
> + if (in >= KS_f1 && in <= KS_f4) {
> + *out = vt100_pfkeys[in - KS_f1];
> + return (3);
> }
> - if (in >= KS_F1 && in <= KS_F24) {
> - *out = vt100_fkeys[in - KS_F1];
> - return (5);
> + if (in >= KS_F1 && in <= KS_F4) {
> + *out =
Re: rpki-client and unknown file types
On Fri, Jan 06, 2023 at 02:04:21PM +0100, Claudio Jeker wrote: > Do not fatal out when an unknown filetype shows up. > Also change the message sent from parser/filemode process to main from > type::file::repoid to type::repoid::file since that simplifies the code a > fair amount. Yes, that's much nicer. ok
rpki-client and unknown file types
Do not fatal out when an unknown filetype shows up.
Also change the message sent from parser/filemode process to main from
type::file::repoid to type::repoid::file since that simplifies the code a
fair amount.
--
:wq Claudio
Index: filemode.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/filemode.c,v
retrieving revision 1.18
diff -u -p -r1.18 filemode.c
--- filemode.c 29 Nov 2022 10:33:09 - 1.18
+++ filemode.c 5 Jan 2023 10:09:45 -
@@ -534,6 +534,7 @@ parse_file(struct entityq *q, struct msg
b = io_new_buffer();
io_simple_buffer(b, >type, sizeof(entp->type));
+ io_simple_buffer(b, >repoid, sizeof(entp->repoid));
io_str_buffer(b, entp->file);
io_close_buffer(msgq, b);
entity_free(entp);
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.229
diff -u -p -r1.229 main.c
--- main.c 15 Dec 2022 12:02:29 - 1.229
+++ main.c 5 Jan 2023 10:08:55 -
@@ -548,6 +548,7 @@ entity_process(struct ibuf *b, struct st
* We follow that up with whether the resources didn't parse.
*/
io_read_buf(b, , sizeof(type));
+ io_read_buf(b, , sizeof(id));
io_read_str(b, );
/* in filemode messages can be ignored, only the accounting matters */
@@ -559,7 +560,6 @@ entity_process(struct ibuf *b, struct st
goto done;
}
- io_read_buf(b, , sizeof(id));
rp = repo_byid(id);
repo_stat_inc(rp, type, STYPE_OK);
switch (type) {
@@ -638,7 +638,8 @@ entity_process(struct ibuf *b, struct st
case RTYPE_FILE:
break;
default:
- errx(1, "unknown entity type %d", type);
+ warnx("%s: unknown entity type %d", file, type);
+ break;
}
done:
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.81
diff -u -p -r1.81 parser.c
--- parser.c15 Dec 2022 12:02:29 - 1.81
+++ parser.c5 Jan 2023 10:08:05 -
@@ -630,14 +630,13 @@ parse_entity(struct entityq *q, struct m
/* pass back at least type, repoid and filename */
b = io_new_buffer();
io_simple_buffer(b, >type, sizeof(entp->type));
+ io_simple_buffer(b, >repoid, sizeof(entp->repoid));
file = NULL;
f = NULL;
switch (entp->type) {
case RTYPE_TAL:
io_str_buffer(b, entp->file);
- io_simple_buffer(b, >repoid,
- sizeof(entp->repoid));
if ((tal = tal_parse(entp->file, entp->data,
entp->datasz)) == NULL)
errx(1, "%s: could not parse tal file",
@@ -649,8 +648,6 @@ parse_entity(struct entityq *q, struct m
case RTYPE_CER:
file = parse_load_file(entp, , );
io_str_buffer(b, file);
- io_simple_buffer(b, >repoid,
- sizeof(entp->repoid));
if (entp->data != NULL)
cert = proc_parser_root_cert(file,
f, flen, entp->data, entp->datasz,
@@ -677,14 +674,10 @@ parse_entity(struct entityq *q, struct m
file = parse_filepath(entp->repoid, entp->path,
entp->file, entp->location);
io_str_buffer(b, file);
- io_simple_buffer(b, >repoid,
- sizeof(entp->repoid));
break;
case RTYPE_MFT:
file = proc_parser_mft(entp, );
io_str_buffer(b, file);
- io_simple_buffer(b, >repoid,
- sizeof(entp->repoid));
c = (mft != NULL);
io_simple_buffer(b, , sizeof(int));
if (mft != NULL)
@@ -694,8 +687,6 @@ parse_entity(struct entityq *q, struct m
case RTYPE_ROA:
file = parse_load_file(entp, , );
io_str_buffer(b, file);
- io_simple_buffer(b, >repoid,
- sizeof(entp->repoid));
roa = proc_parser_roa(file, f, flen);
c = (roa != NULL);
io_simple_buffer(b, , sizeof(int));
@@ -706,15 +697,11 @@ parse_entity(struct entityq *q, struct m
case RTYPE_GBR:
file = parse_load_file(entp, , );
io_str_buffer(b, file);
-
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 05:42:31PM -0300, Crystal Kolipe wrote: | Hopefully it'll fix the problem. Tested with tmux, the spurious ^@'s are now indeed gone. I see there's a new diff available, so I'll try that out in a bit. Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Making wscons a bit more like xterm
This version of the patchset updates a few things since the one posted early
on Wednesday:
NEW - Fix two off-by-ones that caused spurious trailing null characters when
requesting the terminal IDs. (Noticed by Paul running tmux.)
NEW - Discard any parameters passed to a CSI 38 m or CSI 48 m sequence.
See below for more discussion on this.
NEW - Tweaked dim attribute to work correctly on byte-swapped framebuffers.
* Control sequences for dim text, invisible text, strike through, italic, and
double underline attributes are now recognised and set flags in wscons.
* Rendering of dim, invisible, struck, and double underlined text is now
supported in rasops32.c, so users of 32bpp displays will see these text
effects on the console.
* The default number of scrollback screens has been increased from five to
twenty.
* F1 - F4 and F13 - F24 now send different sequences.
* With numlock OFF, keypad 5 is now 'begin' rather than unused.
* Home, End, keypad home, and keypad end now send different sequences.
* A new keysym has been added - KS_Backtab.
* Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
* Shift-F1 - Shift-F12 now send F13 - F24.
* Five new escape sequences added for cursor movement.
Off by ones:
These can actually be triggered with the existing console code, without even
applying any of my patches, and stem from using sizeof with a string constant,
which returns the length of the string _including_ the terminating null.
CSI 38 m and CSI 48 m sequences:
The 30-37 codes set one of eight fixed foreground colours, the 40-47 codes set
the background in the same way. Codes 39 and 49 reset to the default colours.
Codes 38 and 48 have become used as an escape to a larger colour space,
typically 256 colours or 24-bit colour.
A typical invocation to select colour 100 from a 256 colour palette might be:
CSI 38;5;100m
Such sequences are not defined in the terminfo entry for xterm. However, some
programs use them, assuming that they are supported.
The current wscons code ignores the unimplemented 38, but then proceeds to
interpret 5 and 100 as further SGR codes.
In many cases, this doesn't much of a problem, because although 5 enables
blink, none of the rasops code supports blink anyway. However, the last value
can potentially set any SGR attribute. So, for example:
CSI 38;5;4m
...will not select colour 4 as the program is expecting, but instead turn on
underlining.
To avoid this, the lastest version of my patch simply discards all values
after a 38 or 48, until the trailing 'm'.
This works to avoid setting unwanted attributes, until such time as 256 colour
support is added, (if this is even desired).
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@
