Re: CVS commit: src/usr.bin/xlint/lint1

[Roland Illig]

On 18.04.2021 16:12, Christos Zoulas wrote:

In article <20210418085205.10b75f...@cvs.netbsd.org>,
Roland Illig  wrote:

-=-=-=-=-=-

Module Name:src
Committed By:   rillig
Date:   Sun Apr 18 08:52:04 UTC 2021

Modified Files:
src/usr.bin/xlint/lint1: err.c externs1.h lint1.h

Log Message:
lint: add error_at, warning_at, message_at



Isn't it better to pass "const pos_t *", instead of pos_t which needs to
copy the struct?


Thanks for the suggestion, I just changed that.

Roland

Re: CVS commit: src/usr.bin/xlint/lint1

[Christos Zoulas]

In article <20210418085205.10b75f...@cvs.netbsd.org>,
Roland Illig  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  rillig
>Date:  Sun Apr 18 08:52:04 UTC 2021
>
>Modified Files:
>   src/usr.bin/xlint/lint1: err.c externs1.h lint1.h
>
>Log Message:
>lint: add error_at, warning_at, message_at
>
>Right now there are several places in the code that use the global
>variable curr_pos for passing a parameter to the diagnostic functions.
>That's not what global variables are for.
>
>Make it easy for the code to migrate to the parameter-passing style.
>

Isn't it better to pass "const pos_t *", instead of pos_t which needs to
copy the struct?

christos

Re: CVS commit: src/usr.bin/xlint/lint1

[Roland Illig]

On 09.01.2021 17:42, Martin Husemann wrote:

On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:

I guess a simple "make clean && make" will clear up the situation.


Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove all lint objdirs completely).

Please add an entry to src/UPDATING, I would suggest something like:

find $OBJDIR -type d -name \*lint\* | xargs rm -rf


Thanks for the suggestion, I first did that.  I was unsatisfied though
that people would actively have to read src/UPDATING.

Therefore, after reproducing the problem locally, I renamed ops.c to
oper.c, after which the build ran successfully.

Roland

Re: CVS commit: src/usr.bin/xlint/lint1

[Martin Husemann]

On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:
> I guess a simple "make clean && make" will clear up the situation.

Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove all lint objdirs completely).

Please add an entry to src/UPDATING, I would suggest something like:

find $OBJDIR -type d -name \*lint\* | xargs rm -rf

Martin

Re: CVS commit: src/usr.bin/xlint/lint1

[Roland Illig]

On 09.01.2021 12:42, Jared McNeill wrote:

Not sure if it is this exact change, but I am no longer able to build
tools on Ubuntu 20.04.1:

--- lint1 ---
#  link  lint1/lint1
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'


That's weird for several reasons:

1. The word STRUCT_ASSIGN no longer appears in the whole source tree, as
I removed the macro.

2. The compiler should have already caught this "implicit function
declaration" with -Werror and never let the linker see this.

I guess a simple "make clean && make" will clear up the situation.

Roland

Re: CVS commit: src/usr.bin/xlint/lint1

[Jared McNeill]

Not sure if it is this exact change, but I am no longer able to build 
tools on Ubuntu 20.04.1:


--- lint1 ---
#  link  lint1/lint1
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
-I/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/include/compat 
-I/home/jmcneill/netbsd/cvs-src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 
-D_FILE_OFFSET_BITS=64 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1 -I. 
-DPASS=\"lint1.h\" 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../arch/aarch64 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../common 
-o lint1 cgram.lo decl.lo emit.lo emit1.lo err.lo func.lo init.lo 
inittyp.lo main1.lo mem.lo mem1.lo ops.lo print.lo scan.lo tree.lo 
tyname.lo 
-L/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/lib 
-lnbcompat -lrt -lz -lm

/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
collect2: error: ld returned 1 exit status
*** [lint1] Error code 1

nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
1 error

nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1

nbmake[2]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1

*** Failed target:  dependall-lint1
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; 
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this=""; 
real="/home/jmcneill/netbsd/cvs-src/tools" ;; *) this="${dir}/"; 
real="/home/jmcneill/netbsd/cvs-src/tools/${dir}" ;; esac; 
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd 
"${real}" && 
/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/bin/nbmake 
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget lint1 dependall

*** Error code 2

Stop.
nbmake[1]: stopped in /home/jmcneill/netbsd/cvs-src/tools
*** [build_install] Error code 1

nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools
1 error

nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools

ERROR: Failed to make build_install in "tools"
*** BUILD ABORTED ***


On Tue, 5 Jan 2021, Roland Illig wrote:


Module Name:src
Committed By:   rillig
Date:   Tue Jan  5 23:50:29 UTC 2021

Modified Files:
src/usr.bin/xlint/lint1: Makefile op.h ops.def
Added Files:
src/usr.bin/xlint/lint1: ops.c
Removed Files:
src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h mkops

Log Message:
lint: clean up generation of the operator tables

Instead of running a shell program that runs an AWK program that
generates the two files ops.c and ops.h, just define the operator tables
once in ops.def and use these definitions flexibly in ops.c and op.h.


To generate a diff of this commit:
cvs rdiff -u -r1.55 -r1.56 src/usr.bin/xlint/lint1/Makefile
cvs rdiff -u -r1.3 -r0 src/usr.bin/xlint/lint1/Makefile.ops-c \
   src/usr.bin/xlint/lint1/Makefile.ops-h
cvs rdiff -u -r1.13 -r0 src/usr.bin/xlint/lint1/mkops
cvs rdiff -u -r1.9 -r1.10 src/usr.bin/xlint/lint1/op.h
cvs rdiff -u -r0 -r1.1 src/usr.bin/xlint/lint1/ops.c
cvs rdiff -u -r1.6 -r1.7 src/usr.bin/xlint/lint1/ops.def

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/usr.bin/xlint/lint1

[Christos Zoulas]

In article <20160721050113.ga1...@netbsd.org>,
David Holland   wrote:
>On Wed, Jul 20, 2016 at 02:14:12PM -0400, Christos Zoulas wrote:
> > Modified Files:
> > src/usr.bin/xlint/lint1: cgram.y
> > 
> > Log Message:
> > accept attributes in param decls
>
>Parsing gcc attributes "correctly" (as in, where gcc accepts them) is
>a trainwreck. Do we really want to bother trying?

It is actually pretty simple now; I am just discovering new places :-)

christos

Re: CVS commit: src/usr.bin/xlint/lint1

[David Holland]

On Wed, Jul 20, 2016 at 02:14:12PM -0400, Christos Zoulas wrote:
 > Modified Files:
 >  src/usr.bin/xlint/lint1: cgram.y
 > 
 > Log Message:
 > accept attributes in param decls

Parsing gcc attributes "correctly" (as in, where gcc accepts them) is
a trainwreck. Do we really want to bother trying?

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/usr.bin/xlint/lint1

[Alan Barrett]

On Fri, 18 Apr 2014, matthew green wrote:
don't include fmemopen in tools builds. Since tools does not 
define _NETBSD_SOURCE, we don't get the fmemopen prototype


hmm is that because we define _SOMEOTHER_SOURCE?

_NETBSD_SOURCE should be defined normally, unless you start to 
ask for restricted namespaces...


src/tools/compat/compat_defs.h goes to a lot of trouble to ensure 
that _NETBSD_SOURCE does not get defined.  I don't understand why 
that is done.


--apb (Alan Barrett)

re: CVS commit: src/usr.bin/xlint/lint1

[Christos Zoulas]

On Apr 18,  3:24pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/usr.bin/xlint/lint1

| 
| Christos Zoulas writes:
|  Module Name:src
|  Committed By:   christos
|  Date:   Fri Apr 18 02:17:14 UTC 2014
|  
|  Modified Files:
|  src/usr.bin/xlint/lint1: main1.c
|  
|  Log Message:
|  don't include fmemopen in tools builds. Since tools does not define
|  _NETBSD_SOURCE, we don't get the fmemopen prototype
| 
| hmm is that because we define _SOMEOTHER_SOURCE?
| 
| _NETBSD_SOURCE should be defined normally, unless you start to ask
| for restricted namespaces...

Yes, I think we define _POSIX_SOURCE. fmemopen is problematic because
it uses funopen() which cannot be easily implemented with 3rd party
stdio.

christos

re: CVS commit: src/usr.bin/xlint/lint1

[matthew green]

Alan Barrett writes:
 On Fri, 18 Apr 2014, matthew green wrote:
  don't include fmemopen in tools builds. Since tools does not 
  define _NETBSD_SOURCE, we don't get the fmemopen prototype
 
  hmm is that because we define _SOMEOTHER_SOURCE?
 
  _NETBSD_SOURCE should be defined normally, unless you start to 
  ask for restricted namespaces...
 
 src/tools/compat/compat_defs.h goes to a lot of trouble to ensure 
 that _NETBSD_SOURCE does not get defined.  I don't understand why 
 that is done.

indeed.

that's probably a good idea in general -- it means that we're
going to have a restricted environment for tools, even on netbsd,
which helps keep them portable to other platforms.


.mrg.

re: CVS commit: src/usr.bin/xlint/lint1

[matthew green]

Christos Zoulas writes:
 Module Name:  src
 Committed By: christos
 Date: Fri Apr 18 02:17:14 UTC 2014
 
 Modified Files:
   src/usr.bin/xlint/lint1: main1.c
 
 Log Message:
 don't include fmemopen in tools builds. Since tools does not define
 _NETBSD_SOURCE, we don't get the fmemopen prototype

hmm is that because we define _SOMEOTHER_SOURCE?

_NETBSD_SOURCE should be defined normally, unless you start to ask
for restricted namespaces...


.mrg.

Re: CVS commit: src/usr.bin/xlint/lint1

[Matt Thomas]

On Feb 6, 2011, at 11:57 PM, Antti Kantee wrote:

 On Sun Feb 06 2011 at 19:26:27 -0500, Christos Zoulas wrote:
 Module Name: src
 Committed By:christos
 Date:Mon Feb  7 00:26:27 UTC 2011
 
 Modified Files:
  src/usr.bin/xlint/lint1: mkops
 
 Log Message:
 provide  __arraycount() if not there.
 
 What's the point?  Now if a (future) third party OS uses the protected
 namespace to define an __arraycount macro which does not work like our
 __arraycount things will break.
 
 Why is lint in tools anyway ?)
 (at least as a non-nop)

so the build can make lintlibs

Re: CVS commit: src/usr.bin/xlint/lint1

[Antti Kantee]

On Mon Feb 07 2011 at 00:00:15 -0800, Matt Thomas wrote:
  Why is lint in tools anyway ?)
  (at least as a non-nop)
 
 so the build can make lintlibs

duh.  /brick /me.

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa

Re: CVS commit: src/usr.bin/xlint/lint1

[Antti Kantee]

On Sun Feb 06 2011 at 19:26:27 -0500, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date: Mon Feb  7 00:26:27 UTC 2011
 
 Modified Files:
   src/usr.bin/xlint/lint1: mkops
 
 Log Message:
 provide  __arraycount() if not there.

What's the point?  Now if a (future) third party OS uses the protected
namespace to define an __arraycount macro which does not work like our
__arraycount things will break.

Why is lint in tools anyway ?)
(at least as a non-nop)

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa

Re: CVS commit: src/usr.bin/xlint/lint1

[Frank Kardel]

Are we missing a commit ?

/bin/sh: Can't open 
/fs/raid1a/src/NetBSD/tc-merge/src/usr.bin/xlint/lint1/mkops


*** Failed target:  ops.h
*** Failed command: AWK=/usr/btools/bin/nbawk /bin/sh 
/fs/raid1a/src/NetBSD/tc-merge/src/usr.bin/xlint/lint1/mkops -h 
/fs/raid1a/src/NetBSD/tc-merge/src/tools/lint1/../../usr.bin/xlint/lint1/ops.def 
 ops.h

*** Error code 2

Frank

On 02/05/11 04:09, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Sat Feb  5 03:09:46 UTC 2011

Modified Files:
src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h

Log Message:
fix tools build. Why doesn't .PARSEDIR work?


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/usr.bin/xlint/lint1/Makefile.ops-c \
 src/usr.bin/xlint/lint1/Makefile.ops-h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
   

Re: CVS commit: src/usr.bin/xlint/lint1

[Paul Goyette]

Module Name:src
Committed By:   christos
Date:   Sat Feb  5 03:09:46 UTC 2011

Modified Files:
src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h

Log Message:
fix tools build. Why doesn't .PARSEDIR work?



This doesn't seem to have fixed things.  It appears that ops.h is being 
created in the ${SRC} directory rather than in ${OBJ}, and my automated 
amd64 update-build-and-test testbed [1] fails in both tools/lint1 and 
usr.bin/lint/lint1 on alternate passes.  The cvs update step also 
complains about finding ops.h in the source directory, as in


? tools/lint1/ops.h
or  ? usr.bin/xlint/lint1/ops.h


It appears that gson's build-and-test for i386 [2] is also failing in 
a similar manner.




[1] http://www.whooppee.com/~paul/amd64-results/
[2] http://www.gson.org/netbsd/bugs/build/


-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: CVS commit: src/usr.bin/xlint/lint1

[Christos Zoulas]

On Feb 5, 10:47am, kar...@netbsd.org (Frank Kardel) wrote:
-- Subject: Re: CVS commit: src/usr.bin/xlint/lint1

| Are we missing a commit ?
| 
| /bin/sh: Can't open 
| /fs/raid1a/src/NetBSD/tc-merge/src/usr.bin/xlint/lint1/mkops
| 
| *** Failed target:  ops.h
| *** Failed command: AWK=/usr/btools/bin/nbawk /bin/sh 
| /fs/raid1a/src/NetBSD/tc-merge/src/usr.bin/xlint/lint1/mkops -h 
| 
/fs/raid1a/src/NetBSD/tc-merge/src/tools/lint1/../../usr.bin/xlint/lint1/ops.def
 
|   ops.h
| *** Error code 2

Oops, got it now.

christos

Re: CVS commit: src/usr.bin/xlint/lint1

[Frank Kardel]

Hello Christos !

On 20091003 build release fails with:

dependall === lib/libwrap
   compile  libwrap/fix_options.ln
/src/NetBSD/tc-merge/BUILD.i386/usr/include/netinet/ip.h(153): syntax 
error '__packed' [249]
/src/NetBSD/tc-merge/BUILD.i386/usr/include/netinet/ip.h(154): syntax 
error '__packed' [249]
/fs/raid1a/src/NetBSD/tc-merge/src/lib/libwrap/fix_options.c(137): 
warning: conversion to 'unsigned int' due to prototype, arg #2 [259]


*** Failed target:  fix_options.ln
*** Failed command: CC=/usr/btools/bin/i486--netbsdelf-gcc 
/usr/btools/bin/i486--netbsdelf-lint -chapbxzFS -d 
/src/NetBSD/tc-merge/BUILD.i386/usr/include -DFACILITY=LOG_AUTHPRIV 
-DSEVERITY=LOG_INFO -DREAL_DAEMON_DIR=\/usr/libexec\ -DHOSTS_ACCESS 
-DDAEMON_UMASK=022 -DRFC931_TIMEOUT=10 -DALWAYS_HOSTNAME 
-DHOSTS_ALLOW=\/etc/hosts.allow\ -DHOSTS_DENY=\/etc/hosts.deny\ 
-DPROCESS_OPTIONS -DNETGROUP -DINET6 -D_FORTIFY_SOURCE=2 -i 
/src/NetBSD/tc-merge/src/lib/libwrap/fix_options.c

*** Error code 1

Could it be that there may be an issue left :-)

Frank

Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Fri Oct  2 21:49:30 UTC 2009

Modified Files:
src/usr.bin/xlint/lint1: decl.c

Log Message:
handle bit fields in packed structures.


To generate a diff of this commit:
cvs rdiff -u -r1.50 -r1.51 src/usr.bin/xlint/lint1/decl.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.