Re: opportunity to help: %s audit in mandoc

[attila]

Hi everybody,

Here is an updated list after doing what I said yesterday.  One nit: I
count 25 instances in cgi.c, not 27.

  // 27 cgi.c: all ok
  //   317: msg is only NULL when status == 200
  //   351,353,379,405,409,421,425,497,499,527: compile-time string
  // constants and/or scriptname
  //   552: neither r[i].file nor req->q.manpath can be NULL if we got this far
  //   564,585,809,814: constants or cannot be NULL
  //   878: made it through validate_manpath
  //   915: req.q.manpath is set by caller
  //  1002,1149: compile-time string constant
  //  1163,1164,1169,1170: compile-time constant, dp cannot be NULL there
  //  1180: compile-time string constant
  // 4 dbm.c: all ok
  //85,92,96,102: dbm_map(fname) won
  // 5 dbm_map.c: all ok
  //60,73,80,87,97: open(fname) won
  // // 3 eqn.c: agree with Dariusz
  //305: p cannot be NULL
  //679: def->key is set above if def is NULL
  //   1077: eqnsyms[i].sym cannot be NULL

So I guess I'll start on these next:

   5 html.c:
  20 main.c:
   2 man.c:
   2 man_html.c:
   5 man_macro.c:

... and check you here:

   // 2 man_term.c:

Please check me, too.

   9 man_validate.c:
  37 mandocdb.c:
   2 manpath.c:
  23 mansearch.c:
   4 mdoc_html.c:
   // 10 mdoc_macro.c:
   1 mdoc_man.c:
   2 mdoc_term.c:
  43 mdoc_validate.c:
   6 read.c:
  13 roff.c:
   // 1 tag.c:
   // 1 tbl_layout.c:
   // 1 tbl_opts.c:
   6 term_ps.c:
  11 tree.c:

One thing I noticed in cgi.c, line 1015: what if there are multiple
slashes at the head of path?  I think this can happen unless I'm
missing something.

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: opportunity to help: %s audit in mandoc

[attila]

Dariusz Sendkowski  writes:

> From the list below:
>
>   27 cgi.c:
>4 dbm.c:
>5 dbm_map.c:

I'll start on these three...

>// 3 eqn.c:

... and check you here.  When I get that far I'll post again, or if
it's taking me longer than I thought it would I'll post at the end of
the day anyway.

>5 html.c:
>   20 main.c:
>2 man.c:
>2 man_html.c:
>5 man_macro.c:
>// 2 man_term.c:
>9 man_validate.c:
>   37 mandocdb.c:
>2 manpath.c:
>   23 mansearch.c:
>4 mdoc_html.c:
>// 10 mdoc_macro.c:
>1 mdoc_man.c:
>2 mdoc_term.c:
>   43 mdoc_validate.c:
>6 read.c:
>   13 roff.c:
>// 1 tag.c:
>// 1 tbl_layout.c:
>// 1 tbl_opts.c:
>6 term_ps.c:
>   11 tree.c:
>
> I've checked the commented (//) files so far and they look fine. You can
> recheck or take new ones.
> Unfortunately, I don't have as much time as I'd like to so this goes rather
> slowly.
>

See you in a few hours :-)

Pax, -A

>
>
> 2016-08-09 18:41 GMT+02:00 attila :
>
>> Hi {Ingo,Darius,misc@},
>>
>> Ingo Schwarze  writes:
>>
>> > Hi Dariusz,
>> >
>> > Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200:
>> >
>> >> OK, but from which branch?
>> >
>> > We don't use branches in OpenBSD.
>> > Just use the HEAD of the OpenBSD CVS repository.
>> >
>> > You don't need to worry about merging to the portable mandoc
>> > on mdocml.bsd.lv.  That's a no-brainer i'll take care of.
>> >
>> >> Can the results be sent incrementally?
>> >
>> > Yes, that's ideal.
>> >
>> > Don't work for days before sending anything.  Imagine you misunderstand
>> > something and only learn about your error after having wasted days
>> > of work.  That would be bad.  Or imagine two people start working
>> > on the same task and work for days, both preparing the same huge
>> > report.  That would be a waste, too.  That cannot happen if you
>> > send results incrementally right after finding them.
>>
>> Sorry I'm late to the party, as usual, but I had some trouble getting
>> my -current setup back to a reasonable state.  I would like to pitch
>> in on this if it is still needed, and don't want to duplicate work.  I
>> have a list of 221 hits for %s in /usr/src/usr.bin/mandoc in front of
>> me.  Shall I start at the top or has that already happened?
>>
>> > In general, OpenBSD prefers small patches that are easy to understand
>> > and verify, in particular from new contributors.  They need not be
>> > easy to produce, though.
>> >
>> > Yours,
>> >   Ingo
>>
>> Pax, -A
>> --
>> http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF


--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: opportunity to help: %s audit in mandoc

[Dariusz Sendkowski]

>From the list below:

  27 cgi.c:
   4 dbm.c:
   5 dbm_map.c:
   // 3 eqn.c:
   5 html.c:
  20 main.c:
   2 man.c:
   2 man_html.c:
   5 man_macro.c:
   // 2 man_term.c:
   9 man_validate.c:
  37 mandocdb.c:
   2 manpath.c:
  23 mansearch.c:
   4 mdoc_html.c:
   // 10 mdoc_macro.c:
   1 mdoc_man.c:
   2 mdoc_term.c:
  43 mdoc_validate.c:
   6 read.c:
  13 roff.c:
   // 1 tag.c:
   // 1 tbl_layout.c:
   // 1 tbl_opts.c:
   6 term_ps.c:
  11 tree.c:

I've checked the commented (//) files so far and they look fine. You can
recheck or take new ones.
Unfortunately, I don't have as much time as I'd like to so this goes rather
slowly.



2016-08-09 18:41 GMT+02:00 attila :

> Hi {Ingo,Darius,misc@},
>
> Ingo Schwarze  writes:
>
> > Hi Dariusz,
> >
> > Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200:
> >
> >> OK, but from which branch?
> >
> > We don't use branches in OpenBSD.
> > Just use the HEAD of the OpenBSD CVS repository.
> >
> > You don't need to worry about merging to the portable mandoc
> > on mdocml.bsd.lv.  That's a no-brainer i'll take care of.
> >
> >> Can the results be sent incrementally?
> >
> > Yes, that's ideal.
> >
> > Don't work for days before sending anything.  Imagine you misunderstand
> > something and only learn about your error after having wasted days
> > of work.  That would be bad.  Or imagine two people start working
> > on the same task and work for days, both preparing the same huge
> > report.  That would be a waste, too.  That cannot happen if you
> > send results incrementally right after finding them.
>
> Sorry I'm late to the party, as usual, but I had some trouble getting
> my -current setup back to a reasonable state.  I would like to pitch
> in on this if it is still needed, and don't want to duplicate work.  I
> have a list of 221 hits for %s in /usr/src/usr.bin/mandoc in front of
> me.  Shall I start at the top or has that already happened?
>
> > In general, OpenBSD prefers small patches that are easy to understand
> > and verify, in particular from new contributors.  They need not be
> > easy to produce, though.
> >
> > Yours,
> >   Ingo
>
> Pax, -A
> --
> http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: opportunity to help: %s audit in mandoc

[attila]

Hi {Ingo,Darius,misc@},

Ingo Schwarze  writes:

> Hi Dariusz,
>
> Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200:
>
>> OK, but from which branch?
>
> We don't use branches in OpenBSD.
> Just use the HEAD of the OpenBSD CVS repository.
>
> You don't need to worry about merging to the portable mandoc
> on mdocml.bsd.lv.  That's a no-brainer i'll take care of.
>
>> Can the results be sent incrementally?
>
> Yes, that's ideal.
>
> Don't work for days before sending anything.  Imagine you misunderstand
> something and only learn about your error after having wasted days
> of work.  That would be bad.  Or imagine two people start working
> on the same task and work for days, both preparing the same huge
> report.  That would be a waste, too.  That cannot happen if you
> send results incrementally right after finding them.

Sorry I'm late to the party, as usual, but I had some trouble getting
my -current setup back to a reasonable state.  I would like to pitch
in on this if it is still needed, and don't want to duplicate work.  I
have a list of 221 hits for %s in /usr/src/usr.bin/mandoc in front of
me.  Shall I start at the top or has that already happened?

> In general, OpenBSD prefers small patches that are easy to understand
> and verify, in particular from new contributors.  They need not be
> easy to produce, though.
>
> Yours,
>   Ingo

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: opportunity to help: %s audit in mandoc

[Ingo Schwarze]

Hi Dariusz,

Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 08:27:07PM +0200:

> OK, but from which branch?

We don't use branches in OpenBSD.
Just use the HEAD of the OpenBSD CVS repository.

You don't need to worry about merging to the portable mandoc
on mdocml.bsd.lv.  That's a no-brainer i'll take care of.

> Can the results be sent incrementally?

Yes, that's ideal.

Don't work for days before sending anything.  Imagine you misunderstand
something and only learn about your error after having wasted days
of work.  That would be bad.  Or imagine two people start working
on the same task and work for days, both preparing the same huge
report.  That would be a waste, too.  That cannot happen if you
send results incrementally right after finding them.

In general, OpenBSD prefers small patches that are easy to understand
and verify, in particular from new contributors.  They need not be
easy to produce, though.

Yours,
  Ingo

Re: opportunity to help: %s audit in mandoc

[Dariusz Sendkowski]

OK, but from which branch?
Can the results be sent incrementally?

2016-08-07 19:57 GMT+02:00 Ingo Schwarze :

> Hi,
>
> from time to time, people ask how they can help OpenBSD development
> if they are new to that task.
>
> Right now, there is a useful opportunity.  Take the code in
> /usr/src/usr.bin/mandoc/, grep(1) it for "%s", and audit all instances
> you find, figuring out whether they can be reached with the char *
> being NULL or not.  If you find one where the pointer can be NULL,
> construct an input file and a command line (for example, "'mandoc
> -Tlint foo.mdoc' or 'makewhatis -t foo.mdoc' with the attached
> file foo.mdoc") demonstrating that man(1), apropos(1), mandoc(1),
> or makewhatis(8) actually print "(null)", and send the report to
> me.
>
> The task is not very difficult, but requires considerable time (i
> guess i would need up to two days to do the full audit, even though
> i know the code very well).  I have a huge backlog of patches to
> check and a huge backlog of tricky programming tasks to tackle.
> Once somebody finds these issues for me, fixing them is trivial,
> and i can focus on work that is less easy to do for newcomers.
>
> Besides, this will improve your code reading and auditing skills.
> If you find a few things, you could even try to tackle other
> parts of the tree which are more difficult.
>
> In mandoc, there are almost certainly some instances because
> until now, i wasn't aware that printf("%s", NULL) is problematic.
>
> Yours,
>   Ingo

opportunity to help: %s audit in mandoc

[Ingo Schwarze]

Hi,

from time to time, people ask how they can help OpenBSD development
if they are new to that task.

Right now, there is a useful opportunity.  Take the code in
/usr/src/usr.bin/mandoc/, grep(1) it for "%s", and audit all instances
you find, figuring out whether they can be reached with the char *
being NULL or not.  If you find one where the pointer can be NULL,
construct an input file and a command line (for example, "'mandoc
-Tlint foo.mdoc' or 'makewhatis -t foo.mdoc' with the attached
file foo.mdoc") demonstrating that man(1), apropos(1), mandoc(1),
or makewhatis(8) actually print "(null)", and send the report to
me.

The task is not very difficult, but requires considerable time (i
guess i would need up to two days to do the full audit, even though
i know the code very well).  I have a huge backlog of patches to
check and a huge backlog of tricky programming tasks to tackle.
Once somebody finds these issues for me, fixing them is trivial,
and i can focus on work that is less easy to do for newcomers.

Besides, this will improve your code reading and auditing skills.
If you find a few things, you could even try to tackle other
parts of the tree which are more difficult.

In mandoc, there are almost certainly some instances because
until now, i wasn't aware that printf("%s", NULL) is problematic.

Yours,
  Ingo