-Tlint parser errors and warnings to stdout

-Tlint parser errors and warnings to stdout

[Ingo Schwarze]

Hi,

Joerg Sonnenberger wrote on Tue, Sep 27, 2011 at 07:14:27AM +0200:
> On Tue, Sep 27, 2011 at 01:06:32AM +0200, Kristaps Dzonsons wrote:

>> The -Tlint thing is a different story.  At first I thought (Ingo
>> will recognise this behaviour) No Way In Hell.  But (1) mdoclint in
>> regress pushes to stdout; (2) lint itself pushes to stdout; and (3)
>> there's no real notion of portability/compat so we can do what works
>> best for us. So basically I'm fine with sticking a dup2 in there if
>> people think it will save time and effort.

> ...or do some refactoring and replace stderr with errout and just
> reassign the variable?

Here is a patch doing it in about that way, only slightly different.
Restore the half-removed curparse argument to mandocmsg(),
than use that to either select stderr or stdout
for parser diagnostic output.

OK?
  Ingo


Index: main.c
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/main.c,v
retrieving revision 1.78
diff -u -p -r1.78 main.c
--- main.c	17 Sep 2011 14:45:22 -0000	1.78
+++ main.c	28 Sep 2011 09:08:05 -0000
@@ -59,7 +59,8 @@ struct	curparse {
 
 static	int		  moptions(enum mparset *, char *);
 static	void		  mmsg(enum mandocerr, enum mandoclevel,
-				const char *, int, int, const char *);
+				const char *, int, int, const char *,
+				void *);
 static	void		  parse(struct curparse *, int, 
 				const char *, enum mandoclevel *);
 static	int		  toptions(struct curparse *, char *);
@@ -370,16 +371,22 @@ woptions(struct curparse *curp, char *ar
 
 static void
 mmsg(enum mandocerr t, enum mandoclevel lvl, 
-		const char *file, int line, int col, const char *msg)
+		const char *file, int line, int col, const char *msg,
+		void *arg)
 {
+	struct curparse	*curp;
+	FILE		*stream;
 
-	fprintf(stderr, "%s:%d:%d: %s: %s", 
+	curp = (struct curparse *)arg;
+	stream = OUTT_LINT == curp->outtype ? stdout : stderr;
+
+	fprintf(stream, "%s:%d:%d: %s: %s",
 			file, line, col + 1, 
 			mparse_strlevel(lvl),
 			mparse_strerror(t));
 
 	if (msg)
-		fprintf(stderr, ": %s", msg);
+		fprintf(stream, ": %s", msg);
 
-	fputc('\n', stderr);
+	fputc('\n', stream);
 }
Index: mandoc.h
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/mandoc.h,v
retrieving revision 1.40
diff -u -p -r1.40 mandoc.h
--- mandoc.h	18 Sep 2011 10:25:28 -0000	1.40
+++ mandoc.h	28 Sep 2011 09:08:05 -0000
@@ -391,7 +391,7 @@ enum	mandoc_esc {
 };
 
 typedef	void	(*mandocmsg)(enum mandocerr, enum mandoclevel,
-			const char *, int, int, const char *);
+			const char *, int, int, const char *, void *);
 
 struct	mparse;
 struct	mchars;
Index: read.c
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/read.c,v
retrieving revision 1.3
diff -u -p -r1.3 read.c
--- read.c	18 Sep 2011 10:25:28 -0000	1.3
+++ read.c	28 Sep 2011 09:08:06 -0000
@@ -748,7 +748,7 @@ mandoc_msg(enum mandocerr er, struct mpa
 		return;
 
 	if (m->mmsg)
-		(*m->mmsg)(er, level, m->file, ln, col, msg);
+		(*m->mmsg)(er, level, m->file, ln, col, msg, m->arg);
 
 	if (m->file_status < level)
 		m->file_status = level;
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: -Tlint parser errors and warnings to stdout

[Kristaps Dzonsons]

On 09/28/2011 11:21 AM, Ingo Schwarze wrote:
> Hi,
>
> Joerg Sonnenberger wrote on Tue, Sep 27, 2011 at 07:14:27AM +0200:
>> On Tue, Sep 27, 2011 at 01:06:32AM +0200, Kristaps Dzonsons wrote:
>
>>> The -Tlint thing is a different story.  At first I thought (Ingo
>>> will recognise this behaviour) No Way In Hell.  But (1) mdoclint in
>>> regress pushes to stdout; (2) lint itself pushes to stdout; and (3)
>>> there's no real notion of portability/compat so we can do what works
>>> best for us. So basically I'm fine with sticking a dup2 in there if
>>> people think it will save time and effort.
>
>> ...or do some refactoring and replace stderr with errout and just
>> reassign the variable?
>
> Here is a patch doing it in about that way, only slightly different.
> Restore the half-removed curparse argument to mandocmsg(),
> than use that to either select stderr or stdout
> for parser diagnostic output.

Let's hold off on this for a little bit, as there are some elements that 
need thought before going down this road (which I'm ok with, I should 
clarify).  Foremost, since mandoc.3 is built to be a library upstream, 
system errors should be reporting by the same (or parallel) interface as 
mandoc parse errors---NOT using perror or whatnot.  This has bugged me 
for a while, but I've not had the motivation to fix it---let me do so 
before we continue along this road.

Thanks,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: -Tlint parser errors and warnings to stdout

[Ingo Schwarze]

Hi Kristaps,

Kristaps Dzonsons wrote on Sun, Oct 02, 2011 at 05:12:52PM +0200:
> On 09/28/2011 11:21 AM, Ingo Schwarze wrote:
>> Joerg Sonnenberger wrote on Tue, Sep 27, 2011 at 07:14:27AM +0200:
>>> On Tue, Sep 27, 2011 at 01:06:32AM +0200, Kristaps Dzonsons wrote:

>>>> The -Tlint thing is a different story.  At first I thought (Ingo
>>>> will recognise this behaviour) No Way In Hell.  But (1) mdoclint in
>>>> regress pushes to stdout; (2) lint itself pushes to stdout; and (3)
>>>> there's no real notion of portability/compat so we can do what works
>>>> best for us. So basically I'm fine with sticking a dup2 in there if
>>>> people think it will save time and effort.

>>> ...or do some refactoring and replace stderr with errout and just
>>> reassign the variable?

>> Here is a patch doing it in about that way, only slightly different.
>> Restore the half-removed curparse argument to mandocmsg(),
>> than use that to either select stderr or stdout
>> for parser diagnostic output.

> Let's hold off on this for a little bit, as there are some elements
> that need thought before going down this road (which I'm ok with, I
> should clarify).  Foremost, since mandoc.3 is built to be a library
> upstream, system errors should be reporting by the same (or
> parallel) interface as mandoc parse errors---NOT using perror or
> whatnot.  This has bugged me for a while, but I've not had the
> motivation to fix it---let me do so before we continue along this
> road.

No problem, so i'm postponing my patch until you have done the
cleanup.  No particular hurry, but if we want to do it, i think
we should get it off the table until about the end of the year,
to not get too close to the 5.1 release phase.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv