src/libexec/getty, branch stable/12 FreeBSD source tree Revert "Do a sweep and remove most WARNS=6 settings" 2021-08-29T13:28:30+00:00 Dimitry Andric dim@FreeBSD.org 2021-08-29T13:28:30+00:00 e92630fc682954a7b4f724f4a8174d196d7d9cc5 This reverts commit befc47822966, as it caused various CI build errors, and we never merged the prerequisite commit fe815331bb40 ("build: provide a default WARNS for all in-tree builds"). The latter is rather intrusive, so I will avoid it. Direct commit to stable/12 since the CI bots are broken. 
This reverts commit befc47822966, as it caused various CI build errors,
and we never merged the prerequisite commit fe815331bb40 ("build:
provide a default WARNS for all in-tree builds"). The latter is rather
intrusive, so I will avoid it.

Direct commit to stable/12 since the CI bots are broken.
Do a sweep and remove most WARNS=6 settings 2021-08-29T10:49:28+00:00 Kyle Evans kevans@FreeBSD.org 2020-10-01T01:10:51+00:00 befc478229660bca9cbda38d73f6b9d7c8918ded Repeating the default WARNS here makes it slightly more difficult to experiment with default WARNS changes, e.g. if we did something absolutely bananas and introduced a WARNS=7 and wanted to try lifting the default to that. Drop most of them; there is one in the blake2 kernel module, but I suspect it should be dropped -- the default WARNS in the rest of the build doesn't currently apply to kernel modules, and I haven't put too much thought into whether it makes sense to make it so. (cherry picked from commit 7cc42f6d25ef2e19059d088fa7d4853fe9afefb5) 
Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.

Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.

(cherry picked from commit 7cc42f6d25ef2e19059d088fa7d4853fe9afefb5)
MFC r363408: 2020-09-09T22:40:14+00:00 Warner Losh imp@FreeBSD.org 2020-09-09T22:40:14+00:00 3efa62d3b8706c55e05ba8c57c58e1921a6ecad4 r363408 | imp | 2020-07-21 18:44:47 -0600 (Tue, 21 Jul 2020) | 4 lines getty appears to date from 3rd edition research unix. That's the oldest man page on TUHS and its 'unix 1972' restoration effort has assembler sources that look like simpler version of what's in the 5th edition. 
r363408 | imp | 2020-07-21 18:44:47 -0600 (Tue, 21 Jul 2020) | 4 lines

getty appears to date from 3rd edition research unix. That's the oldest man page
on TUHS and its 'unix 1972' restoration effort has assembler sources that look
like simpler version of what's in the 5th edition.
MFC r355222, r355260: 2019-12-15T08:23:38+00:00 Xin LI delphij@FreeBSD.org 2019-12-15T08:23:38+00:00 a23ed3f1ad8ccb2b1d72b9b5ffc4e7bcf362bbb6 r355222: Use strlcat(). r355260: Simplify code with strlcpy/strlcat. 
r355222: Use strlcat().
r355260: Simplify code with strlcpy/strlcat.
MFC r343479: Fix potential buffer overflow and undefined behavior. 2019-02-09T14:21:29+00:00 Stefan Eßer se@FreeBSD.org 2019-02-09T14:21:29+00:00 4af3ade922874be16a68ffddd7c5413d544a2040 The buffer allocated in read_chat() could be 1 element too short, if the chatstr parameter passed in is 1 or 3 charachters long (e.g. "a" or "a b"). The allocation of the pointer array does not account for the terminating NULL pointer in that case. Overlapping source and destination strings are undefined in strcpy(). Instead of moving a string to the left by one character just increment the char pointer before it is assigned to the results array. 
The buffer allocated in read_chat() could be 1 element too short, if the
chatstr parameter passed in is 1 or 3 charachters long (e.g. "a" or "a b").
The allocation of the pointer array does not account for the terminating
NULL pointer in that case.

Overlapping source and destination strings are undefined in strcpy().
Instead of moving a string to the left by one character just increment the
char pointer before it is assigned to the results array.
Move gettytab to libexec/getty/ 2018-09-05T15:25:23+00:00 Brad Davis brd@FreeBSD.org 2018-09-05T15:25:23+00:00 ce9e223ebd9c3fc9225b1d45d598fe2988f64dde Approved by: re (gjb), will (mentor) Differential Revision: https://reviews.freebsd.org/D16953 
Approved by:	re (gjb), will (mentor)
Differential Revision:	https://reviews.freebsd.org/D16953
Remove pointless comment. 2018-08-03T10:59:05+00:00 Edward Tomasz Napierala trasz@FreeBSD.org 2018-08-03T10:59:05+00:00 b32ae5fe795d684389f353edd8b7a4df827e3b5d MFC after: 2 weeks Sponsored by: DARPA, AFRL 
MFC after:	2 weeks
Sponsored by:	DARPA, AFRL
.Xr pam_securetty(8) from ttys(5), to hint the users as to what actually 2018-08-03T10:58:13+00:00 Edward Tomasz Napierala trasz@FreeBSD.org 2018-08-03T10:58:13+00:00 b6784423605b1d5ce6d1dfab57084f192acd47e4 enforces the 'secure' tty flag. MFC after: 2 weeks Sponsored by: DARPA, AFRL 
enforces the 'secure' tty flag.

MFC after:	2 weeks
Sponsored by:	DARPA, AFRL
.Xr pstat(8), so that people have a chance to learn how to get a list 2018-03-02T14:16:19+00:00 Edward Tomasz Napierala trasz@FreeBSD.org 2018-03-02T14:16:19+00:00 7a467312ef9f4c8f354d5747b2312b1fbe4a18dd of terminal devices using "pstat -t". MFC after: 2 weeks Sponsored by: The FreeBSD Foundation 
of terminal devices using "pstat -t".

MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Fix gettytab(5) to document f0, f1, and f2 as unsupported; they've been gone 2018-02-26T17:51:18+00:00 Edward Tomasz Napierala trasz@FreeBSD.org 2018-02-26T17:51:18+00:00 fe3f4a580a73ffe6ff14ec6a1169912f3ff2d5a2 since r131091. PR: 184691 (partial) Submitted by: naddy@ MFC after: 2 weeks Sponsored by: The FreeBSD Foundation 
since r131091.

PR:             184691 (partial)
Submitted by:   naddy@
MFC after:      2 weeks
Sponsored by:   The FreeBSD Foundation