* Naive patch for handling empty input
@ 2023-10-13 7:30 Baptiste Daroussin
2023-10-13 10:13 ` Ingo Schwarze
0 siblings, 1 reply; 6+ messages in thread
From: Baptiste Daroussin @ 2023-10-13 7:30 UTC (permalink / raw)
To: tech
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
Hello,
Please find attached a naive patch to handle dealing with empty
This is probably a two naive approach, but I didn't want to come with empty
hands :D
the issue is the following:
./mandoc </dev/null
before the patch is show 3 lines
after nothing
Best regards,
Bapt
[-- Attachment #2: emptyinput.diff --]
[-- Type: text/x-diff, Size: 2183 bytes --]
Index: cgi.c
===================================================================
RCS file: /cvs/mandoc/cgi.c,v
retrieving revision 1.181
diff -u -r1.181 cgi.c
--- cgi.c 28 Apr 2023 19:11:03 -0000 1.181
+++ cgi.c 13 Oct 2023 07:28:40 -0000
@@ -919,6 +919,8 @@
mparse_readfd(mp, fd, file);
close(fd);
meta = mparse_result(mp);
+ if (meta == NULL)
+ return;
memset(&conf, 0, sizeof(conf));
conf.fragment = 1;
Index: demandoc.c
===================================================================
RCS file: /cvs/mandoc/demandoc.c,v
retrieving revision 1.34
diff -u -r1.34 demandoc.c
--- demandoc.c 14 Apr 2022 16:43:43 -0000 1.34
+++ demandoc.c 13 Oct 2023 07:28:40 -0000
@@ -127,6 +127,8 @@
mparse_readfd(mp, fd, fn);
close(fd);
meta = mparse_result(mp);
+ if (meta == NULL)
+ return;
line = 1;
col = 0;
Index: main.c
===================================================================
RCS file: /cvs/mandoc/main.c,v
retrieving revision 1.361
diff -u -r1.361 main.c
--- main.c 14 Apr 2022 16:43:43 -0000 1.361
+++ main.c 13 Oct 2023 07:28:41 -0000
@@ -983,6 +983,8 @@
mandoc_xr_reset();
meta = mparse_result(mp);
+ if (meta == NULL)
+ return;
/* Execute the out device, if it exists. */
Index: mandocd.c
===================================================================
RCS file: /cvs/mandoc/mandocd.c,v
retrieving revision 1.13
diff -u -r1.13 mandocd.c
--- mandocd.c 14 Apr 2022 16:43:44 -0000 1.13
+++ mandocd.c 13 Oct 2023 07:28:41 -0000
@@ -261,6 +261,8 @@
mparse_readfd(parser, STDIN_FILENO, "<unixfd>");
meta = mparse_result(parser);
+ if (meta == NULL)
+ return;
if (meta->macroset == MACROSET_MDOC) {
switch (outtype) {
case OUTT_ASCII:
Index: read.c
===================================================================
RCS file: /cvs/mandoc/read.c,v
retrieving revision 1.221
diff -u -r1.221 read.c
--- read.c 19 May 2022 14:48:56 -0000 1.221
+++ read.c 13 Oct 2023 07:28:41 -0000
@@ -716,6 +716,8 @@
struct roff_meta *
mparse_result(struct mparse *curp)
{
+ if (curp->line == 0)
+ return (NULL);
roff_state_reset(curp->man);
if (curp->options & MPARSE_VALIDATE) {
if (curp->man->meta.macroset == MACROSET_MDOC)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Naive patch for handling empty input
2023-10-13 7:30 Naive patch for handling empty input Baptiste Daroussin
@ 2023-10-13 10:13 ` Ingo Schwarze
2023-10-13 10:22 ` Baptiste Daroussin
0 siblings, 1 reply; 6+ messages in thread
From: Ingo Schwarze @ 2023-10-13 10:13 UTC (permalink / raw)
To: Baptiste Daroussin; +Cc: tech
Hi Bapt,
Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 09:30:18AM +0200:
> Please find attached a naive patch to handle dealing with empty
Why would you want to do anything like that?
While empty input is valid low-level roff(7) input, it is not a valid
manual page. While mandoc(1) wants to be compatible with groff
in manual pages, it is not a goal to be compatible with respect to
each and every low-level roff(7) feature outside of manual pages.
> This is probably a two naive approach, but I didn't want to come
> with empty hands :D
>
> the issue is the following:
> ./mandoc </dev/null
>
> before the patch is show 3 lines
> after nothing
I guess which approach makes sense for empty input depends on the
reasons *why* you want to handle empty input in any particular way.
So far, i cannot think of any possible reasons.
Also, where do you want to stop?
Do you want the output of
echo foo | mandoc
to become compatible with
echo foo | groff -ket -ww -mtty-char -Tascii -P -c
If yes, your patch is indeed much too naive.
If not, what is so special about empty input compared to other
low-level roff(7) non-manual-page input?
Yours,
Ingo
--
To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Naive patch for handling empty input
2023-10-13 10:13 ` Ingo Schwarze
@ 2023-10-13 10:22 ` Baptiste Daroussin
2023-10-13 11:05 ` Ingo Schwarze
0 siblings, 1 reply; 6+ messages in thread
From: Baptiste Daroussin @ 2023-10-13 10:22 UTC (permalink / raw)
To: tech
On Fri, Oct 13, 2023 at 12:13:49PM +0200, Ingo Schwarze wrote:
> Hi Bapt,
>
> Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 09:30:18AM +0200:
>
> > Please find attached a naive patch to handle dealing with empty
>
> Why would you want to do anything like that?
>
> While empty input is valid low-level roff(7) input, it is not a valid
> manual page. While mandoc(1) wants to be compatible with groff
> in manual pages, it is not a goal to be compatible with respect to
> each and every low-level roff(7) feature outside of manual pages.
>
> > This is probably a two naive approach, but I didn't want to come
> > with empty hands :D
> >
> > the issue is the following:
> > ./mandoc </dev/null
> >
> > before the patch is show 3 lines
> > after nothing
>
> I guess which approach makes sense for empty input depends on the
> reasons *why* you want to handle empty input in any particular way.
> So far, i cannot think of any possible reasons.
>
> Also, where do you want to stop?
>
> Do you want the output of
>
> echo foo | mandoc
>
> to become compatible with
>
> echo foo | groff -ket -ww -mtty-char -Tascii -P -c
>
> If yes, your patch is indeed much too naive.
> If not, what is so special about empty input compared to other
> low-level roff(7) non-manual-page input?
>
I was looking for compatibility with groff like you showed above, this
is an "issue" a user reported, he was expecting to have an empty output
if provided an empty input, but if the current behaviour is how you think
mandoc should behave, I am fine with closing the report with work as intended.
Best regards,
Bapt
--
To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Naive patch for handling empty input
2023-10-13 10:22 ` Baptiste Daroussin
@ 2023-10-13 11:05 ` Ingo Schwarze
2023-10-13 11:22 ` Baptiste Daroussin
0 siblings, 1 reply; 6+ messages in thread
From: Ingo Schwarze @ 2023-10-13 11:05 UTC (permalink / raw)
To: Baptiste Daroussin; +Cc: tech
Hi Bapt,
Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 12:22:09PM +0200:
> I was looking for compatibility with groff like you showed above, this
> is an "issue" a user reported, he was expecting to have an empty output
> if provided an empty input, but if the current behaviour is how you think
> mandoc should behave, I am fine with closing the report with work as
> intended.
It might be useful to ask the user first *why* they want that
particular behaviour, and how they think mandoc(1) should behave
without .TH or .Dd in general, and why they want specific behaviour
in such cases of degenerate input.
It is conceivable that maybe they have an interesting reason,
and knowing that reason might help to make mandoc better?
I'm not sure it will, but i'm not sure that possibility can be
excluded, either.
Yours,
Ingo
--
To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Naive patch for handling empty input
2023-10-13 11:05 ` Ingo Schwarze
@ 2023-10-13 11:22 ` Baptiste Daroussin
2023-10-13 11:52 ` Ingo Schwarze
0 siblings, 1 reply; 6+ messages in thread
From: Baptiste Daroussin @ 2023-10-13 11:22 UTC (permalink / raw)
To: Ingo Schwarze; +Cc: tech
On Fri, Oct 13, 2023 at 01:05:19PM +0200, Ingo Schwarze wrote:
> Hi Bapt,
>
> Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 12:22:09PM +0200:
>
> > I was looking for compatibility with groff like you showed above, this
> > is an "issue" a user reported, he was expecting to have an empty output
> > if provided an empty input, but if the current behaviour is how you think
> > mandoc should behave, I am fine with closing the report with work as
> > intended.
>
> It might be useful to ask the user first *why* they want that
> particular behaviour, and how they think mandoc(1) should behave
> without .TH or .Dd in general, and why they want specific behaviour
> in such cases of degenerate input.
>
> It is conceivable that maybe they have an interesting reason,
> and knowing that reason might help to make mandoc better?
> I'm not sure it will, but i'm not sure that possibility can be
> excluded, either.
I am not sure, the report happened here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274247
Best regards,
Bapt
--
To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Naive patch for handling empty input
2023-10-13 11:22 ` Baptiste Daroussin
@ 2023-10-13 11:52 ` Ingo Schwarze
0 siblings, 0 replies; 6+ messages in thread
From: Ingo Schwarze @ 2023-10-13 11:52 UTC (permalink / raw)
To: Baptiste Daroussin; +Cc: tech
Hi Bapt,
Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 01:22:41PM +0200:
> On Fri, Oct 13, 2023 at 01:05:19PM +0200, Ingo Schwarze wrote:
>> Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 12:22:09PM +0200:
>>> I was looking for compatibility with groff like you showed above, this
>>> is an "issue" a user reported, he was expecting to have an empty output
>>> if provided an empty input, but if the current behaviour is how you think
>>> mandoc should behave, I am fine with closing the report with work as
>>> intended.
>> It might be useful to ask the user first *why* they want that
>> particular behaviour, and how they think mandoc(1) should behave
>> without .TH or .Dd in general, and why they want specific behaviour
>> in such cases of degenerate input.
>>
>> It is conceivable that maybe they have an interesting reason,
>> and knowing that reason might help to make mandoc better?
>> I'm not sure it will, but i'm not sure that possibility can be
>> excluded, either.
> I am not sure, the report happened here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274247
I see, i added an inquiry there, hoping that wosch@ may be able
to clarify why he thinks this "Affects Some People".
Yours,
Ingo
--
To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-10-13 11:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-13 7:30 Naive patch for handling empty input Baptiste Daroussin
2023-10-13 10:13 ` Ingo Schwarze
2023-10-13 10:22 ` Baptiste Daroussin
2023-10-13 11:05 ` Ingo Schwarze
2023-10-13 11:22 ` Baptiste Daroussin
2023-10-13 11:52 ` Ingo Schwarze
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).