Re: CVS commit: src/tests/usr.bin

2020-09-14 Thread Martin Husemann
On Mon, Sep 14, 2020 at 03:17:53PM +, Kamil Rytarowski wrote:
> Enable TSan tests for GCC and >32bit address space environments

Since tsan does not work on all architectures, this is not a good idea.
It would be better to code it with an explicit list of architectures
supported.

Martin


Re: CVS commit: src/usr.bin/make

2020-09-14 Thread Roland Illig

On 14.09.2020 21:05, Robert Elz wrote:

 Date:Mon, 14 Sep 2020 16:16:52 +
 From:"Roland Illig" 
 Message-ID:  <20200914161652.d4eb5f...@cvs.netbsd.org>

   | make(1): inline LPAREN in parse.c
   |
   | It's shorter and more readable, and the other characters don't have
   | named constants as well.

Most likely the reason for that was for parentheses matching editors.

Using '(' creates a ( that (a non C syntax savvy) editor will match
against the next (otherwise unmatched) ')' it finds.   LPAREN doesn't
have that effect.   An alternative is to add a /*)*/ comment on the line,
but that starts getting obtrusive, and difficult to justify.


I've seen all 3 variants in usr.bin/make/*.c, even in the code from
-D2020.01.01.00.00.00, before I started the big rewrite:

$ grep "'[(){}]'" *.c | wc -l
  58

$ grep -Ew 'LPAREN|RPAREN|BROPEN|BRCLOSE|PROPEN|PRCLOSE' *.c \
| wc -l
  19

$ grep '/\*[[:space:]]*[(){}][[:space:]]*\*/' *.c | wc -l
   2

Therefore I had the impression that there was no hard preference, and
that it would be ok to change this.  If it had been consistent over the
majority of the code in usr.bin/make, I would have left it that way.


Re: CVS commit: src/usr.bin/make

2020-09-14 Thread Robert Elz
Date:Mon, 14 Sep 2020 16:16:52 +
From:"Roland Illig" 
Message-ID:  <20200914161652.d4eb5f...@cvs.netbsd.org>

  | make(1): inline LPAREN in parse.c
  |
  | It's shorter and more readable, and the other characters don't have
  | named constants as well.

Most likely the reason for that was for parentheses matching editors.

Using '(' creates a ( that (a non C syntax savvy) editor will match
against the next (otherwise unmatched) ')' it finds.   LPAREN doesn't
have that effect.   An alternative is to add a /*)*/ comment on the line,
but that starts getting obtrusive, and difficult to justify.

kre