Re: CVS commit: src/usr.bin/man
On Sat, Jun 18, 2022 at 02:19:07 +, David H. Gutteridge wrote: > Module Name: src > Committed By: gutteridge > Date: Sat Jun 18 02:19:07 UTC 2022 > > Modified Files: > src/usr.bin/man: man.conf.5 > > Log Message: > man.conf.5: add details about the machine line and search order > > Also, tweak some grammar, style, and markup while here. > > > To generate a diff of this commit: > cvs rdiff -u -r1.27 -r1.28 src/usr.bin/man/man.conf.5 Please, could you rephrase the bit about the _ keyword. It is not quite clear on the first reading which is the keyword and which is the value (epecially in text output where formatting (wrong anyway :) doesn't provide a hint). Using "value" to talk about the keyword doesn't help too. Also, "commonly" in the added phrase is misleading I'd say. Commonly implies "not always", which is false - we suppply x86 as an extra subdir in the default man.conf. I know that passage was not very clear to begin with, but you touch it you buy it :). Not being a native speaker I don't dare touching it, I'm afraid to make more mess. TIA! -uwe
Re: CVS commit: src/usr.bin/man
Am 10.03.2022 um 22:48 schrieb David H. Gutteridge: Module Name:src Committed By: rillig Date: Tue Mar 8 23:13:05 UTC 2022 Modified Files: src/usr.bin/man: man.c Log Message: man: remove unused global variable 'instype' (since yesterday) No functional change. To generate a diff of this commit: cvs rdiff -u -r1.71 -r1.72 src/usr.bin/man/man.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Hi Roland, Hardly the most pressing concern for us to discuss, but, the reason I'd defined that global variable is because that's how NetBSD's "style" document shows it's done in its enum example. I didn't think that was necessary here, but took the "style" example literally. Hi Dave, I agree that taking the "style" example literally could lead to this code, thank you for explaining how you arrived with this code. In fact, when I first saw your code I didn't realize that 'instype' was a variable, I thought it would be a typedef name. Only when I tried to remove this unused name, the generated binary changed, which made me cautious. To avoid future misinterpretation, I fixed the enum example in share/misc/style. As for the other change you made (enum vs. int), I guess that's just bad style on my part. I don't really work in C anymore, but when I did, in my context, we treated enum and int as being interchangable. Good to know. I changed the parameter type from int to enum because this enables stricter checks in the compilers and in lint. They would report a mismatch of enum types then. The enum check in lint is not enabled by default though, but still it is there (LINTFLAGS+= -e in the Makefile). For usr.bin/man, there aren't many enum constants that could be confused, but in other programs like usr.bin/make there are really many of them, and 2 years ago there were even enum constants from different types that used the same prefix "VAR_", which increased the confusion. That's the reason that I prefer to be as specific with enum types as possible. Another benefit is that using 'enum' (or 'bool') instead of 'int' communicates the purpose of the variable more precisely to human readers, and I like this extra bit of precision. Regards, Roland
Re: CVS commit: src/usr.bin/man
> Module Name:src > Committed By: rillig > Date: Tue Mar 8 23:13:05 UTC 2022 > > Modified Files: > src/usr.bin/man: man.c > > Log Message: > man: remove unused global variable 'instype' (since yesterday) > > No functional change. > > > To generate a diff of this commit: > cvs rdiff -u -r1.71 -r1.72 src/usr.bin/man/man.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. Hi Roland, Hardly the most pressing concern for us to discuss, but, the reason I'd defined that global variable is because that's how NetBSD's "style" document shows it's done in its enum example. I didn't think that was necessary here, but took the "style" example literally. As for the other change you made (enum vs. int), I guess that's just bad style on my part. I don't really work in C anymore, but when I did, in my context, we treated enum and int as being interchangable. Good to know. Regards, Dave
re: CVS commit: src/usr.bin/man
Alan Barrett writes: Module Name: src Committed By: apb Date: Thu Aug 14 15:31:12 UTC 2014 Modified Files: src/usr.bin/man: man.c Log Message: For an argument to be interpreted as a local file name, bypassing the search rules in man.conf or MANPATH, it must begin with /, ./, or ../. Simply testing whether it contains / is wrong, because it breaks usage like man 8 vax/boot. This reverts revision 1.57 dated 2013-10-06, Be more permissive in interpreting man pages as filenames. what about trying to stat() it and use it, as a last resort? it's always kind of bothered me man file.1 doesn't work, and the ./ workaround always seems sleezy. .mrg.
Re: CVS commit: src/usr.bin/man
On Thu, Jul 18, 2013 at 11:39:08 -0400, Christos Zoulas wrote: - fix cast qual issues Do you really need EMPTY hack? Why not just (untested) - pg-gl_pathv[cnt] = ; + *pg-gl_pathv[cnt] = '\0'; -uwe
Re: CVS commit: src/usr.bin/man
On Thu, Jul 18, 2013 at 11:39:08 -0400, Christos Zoulas wrote: - don't use snprintf on a user-provided buffer This: - (void)snprintf(buf, sizeof(buf), fmt, escpage, suffix-s); + fixstring(buf, sizeof(buf), fmt, escpage); seems wrong, as it loses suffix-s, doesn't it? And fixstring is a terrible name. -uwe
