Taylor R Campbell wrote:
> Can you please back this out promptly, add automatic tests for
> whatever the underlying issue is, and redo it another way?
I did a scan of miss-use of <>, and looks like libc might
have an issue:
lib/libc/arch/arm/Makefile.inc:28:.include
expects to find
Taylor R Campbell wrote:
>
> --- cleandir-libterminfo ---
> nbmake[5]: "/tmp/build/2024.05.19.20.09.40-i386/src/lib/libterminfo/Makefile"
> line 50: Could not find Makefile.hash
>
> Can you please back this out promptly, add automatic tests for
> whatever the underlying issue is, and redo it
> Module Name:src
> Committed By: sjg
> Date: Sun May 19 20:09:40 UTC 2024
>
> Modified Files:
> src/usr.bin/make: dir.c dir.h parse.c
>
> Log Message:
> make: use separate function to include makefiles.
>
> Have Dir_FindFile and Dir_FindInclude call FindFile with a
>
> On May 3, 2024, at 11:11 AM, Roland Illig wrote:
>
> Am 02.05.2024 um 22:44 schrieb Christos Zoulas:
>> On 2024-05-02 3:04 pm, Christos Zoulas wrote:
>>> This is with clang.
>>>
>> And I don't get it. Gcc produces:
>>
>> if (ignore &&
>> # 139 "base64.c" 3 4
>>
Am 02.05.2024 um 22:44 schrieb Christos Zoulas:
> On 2024-05-02 3:04 pm, Christos Zoulas wrote:
>> This is with clang.
>>
> And I don't get it. Gcc produces:
>
>if (ignore &&
> # 139 "base64.c" 3 4
> ((int)((_ctype_tab_ + 1)[(
> # 139 "base64.c"
> c
> # 139
On 2024-05-02 3:04 pm, Christos Zoulas wrote:
On 2024-05-02 2:47 pm, Roland Illig wrote:
Am 02.05.2024 um 17:45 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Thu May 2 15:45:36 UTC 2024
Modified Files:
src/usr.bin/base64: Makefile
Log Message:
On 2024-05-02 2:47 pm, Roland Illig wrote:
Am 02.05.2024 um 17:45 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Thu May 2 15:45:36 UTC 2024
Modified Files:
src/usr.bin/base64: Makefile
Log Message:
comment out strict boolean lint check because
Am 02.05.2024 um 17:45 schrieb Christos Zoulas:
> Module Name: src
> Committed By: christos
> Date: Thu May 2 15:45:36 UTC 2024
>
> Modified Files:
> src/usr.bin/base64: Makefile
>
> Log Message:
> comment out strict boolean lint check because isspace() returns int and lint
>
Am 14.03.2024 um 21:27 schrieb Robert Elz:
> Date:Thu, 14 Mar 2024 20:53:13 +0100
> From:Roland Illig
> Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de>
>
> | I don't think the flags '+' and '0' make sense for strings, that's why I
> | decided to preserve
Date:Thu, 14 Mar 2024 20:53:13 +0100
From:Roland Illig
Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de>
| I don't think the flags '+' and '0' make sense for strings, that's why I
| decided to preserve existing behavior.
But the change only affected
Am 14.03.2024 um 20:38 schrieb Robert Elz:
> Module Name: src
> Committed By: kre
> Date: Thu Mar 14 19:38:56 UTC 2024
>
> Modified Files:
> src/usr.bin/stat: stat.c
>
> Log Message:
> While the change in 1.51 certainly retained binary compat with
> what was in 1.50 (while silencing
In article <20240218223315.800aff...@cvs.netbsd.org>,
Thomas Klausner wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: wiz
>Date: Sun Feb 18 22:33:15 UTC 2024
>
>Modified Files:
> src/usr.bin/ftp: ftp_var.h
>
>Log Message:
>ftp: bump FTPBUFLEN from 4kB to 16kB
>
On Thu, 25 Jan 2024 20:02:00 +0100, Roland Illig writes:
>>> Modified Files:
>>> src/usr.bin/make: make.1
>>>
>>> Log Message:
>>> Indicate that for :U newval is optional
>>
>> I think this is more confusing than helpful.
>
>I agree. Make doesn't distinguish between an empty string and an
On Thu, 25 Jan 2024 21:12:20 +0100, Roland Illig writes:
>them all. Due to this, I'd go with:
>
>> .It Cm \&:U\| Ns Ar newval
>> If the variable is undefined,
>> .Ar newval
>> (which may be empty) is the value.
That's almost exactly what I had in my 1st cut ;-)
Will do.
>Then, add the same
About optional arguments to modifiers, such as in ${VAR:U}:
Am 25.01.2024 um 20:54 schrieb Simon Gerraty:
> Is there perhaps a general statement somewhere (I may have missed it)
> that could cover all these and be cited to pedantic users?
> Eg to the effect of perhaps, unless stated otherwise
Am 25.01.2024 um 14:25 schrieb Valery Ushakov:
> On Thu, Jan 25, 2024 at 07:35:46 +, Simon J. Gerraty wrote:
>
>> Modified Files:
>> src/usr.bin/make: make.1
>>
>> Log Message:
>> Indicate that for :U newval is optional
>
> I think this is more confusing than helpful.
I agree. Make
On Fri, Sep 8, 2023 at 21:38 matthew green wrote:
> Module Name:src
> Committed By: mrg
> Date: Sat Sep 9 04:38:49 UTC 2023
>
> Modified Files:
> src/usr.bin/make: main.c
>
> Log Message:
> add explicit cast for long -> int truncation warning-as-error.
>
> as this is
Valery Ushakov wrote:
> I think that information *must* be there, as that's *the* place where
> the names are (un)parsed. I'm not sure whether this information has
> to be duplicated as-is in chflags(1), or whether chflags(1) can have a
> less verbose version.
Perhaps a simple
See
On Thu, May 25, 2023 at 09:59:41 -0400, Greg Troxel wrote:
> Taylor R Campbell writes:
>
> > jschauma@'s change did help clarify (1) and (2). Let's try to work
> > together to make it better?
[...]
> I would recommend:
>
> Noting that archive flag represents something in some foreign
>
Date:Thu, 25 May 2023 09:59:41 -0400
From:Greg Troxel
Message-ID:
| Also, the man page does not explain that because "nodump" is the name of
| a flag, one does "chflags dump foo" to remove the nodump flag.
It doesn't really need to, as while that works, so
Taylor R Campbell writes:
> jschauma@'s change did help clarify (1) and (2). Let's try to work
> together to make it better?
Well said.
I can shed a little light on some of the questions.
> 1. What is `arch' or `archived' supposed to mean? Who sets it, who
>pays attention to it, and
> Date: Thu, 25 May 2023 15:10:41 +0300
> From: Valery Ushakov
>
> This new paragraph is wedged right between the list of the options and
> the continuation of that same paragraph that says that they can be
> prefixed with "no".
>
> A description of an obsolete flag right in the middle of the
Valery Ushakov wrote:
> Anyway, this change is strictly for the worse.
¯\_(ツ)_/¯
I've reverted the change.
-Jan
Valery Ushakov writes:
> On Thu, May 25, 2023 at 07:17:52 -0400, Greg Troxel wrote:
>
>> Jan Schaumann writes:
>>
>> > Valery Ushakov wrote:
>> >> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
>> >
>> >> > Briefly describe the 'arch' and 'nodump' flags.
>> >>
>> >> What makes
On Thu, May 25, 2023 at 07:17:52 -0400, Greg Troxel wrote:
> Jan Schaumann writes:
>
> > Valery Ushakov wrote:
> >> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
> >
> >> > Briefly describe the 'arch' and 'nodump' flags.
> >>
> >> What makes them special and why is that these
On Wed, May 24, 2023 at 23:44:07 -0400, Jan Schaumann wrote:
> Valery Ushakov wrote:
> > On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
>
> > > Briefly describe the 'arch' and 'nodump' flags.
> >
> > What makes them special and why is that these two have to be described
> > here
Jan Schaumann writes:
> Valery Ushakov wrote:
>> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
>
>> > Briefly describe the 'arch' and 'nodump' flags.
>>
>> What makes them special and why is that these two have to be described
>> here and not in chflags(2), where the flags are
Valery Ushakov wrote:
> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
> > Briefly describe the 'arch' and 'nodump' flags.
>
> What makes them special and why is that these two have to be described
> here and not in chflags(2), where the flags are actually defined?
Unlike the
On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote:
> Module Name: src
> Committed By: jschauma
> Date: Wed May 24 22:33:17 UTC 2023
>
> Modified Files:
> src/usr.bin/chflags: chflags.1
>
> Log Message:
> Briefly describe the 'arch' and 'nodump' flags.
What makes them
Taylor R Campbell wrote:
> That said, I don't see any reason why this should be a macro in the
> first place. If there is a compelling reason, please write it down;
> if not, please change it to a static function:
>
Sure.
> static BuildMon *
> BM(Job *job)
> {
>
> return (job != NULL
> Module Name:src
> Committed By: sjg
> Date: Sat Feb 25 22:52:22 UTC 2023
>
> Modified Files:
> src/usr.bin/make: meta.c
>
> Log Message:
> meta.c: use macro to access job->bm
>
> and if job is NULL use Mybm.
> +#define BM(job) (job != NULL) ? >bm :
If this must be a
Hi,
matthew green writes:
>> With this change, ldd /lib/libc.so.12.220 fails under NetBSD/amd64 9.99.101.
>>
>>
>> /lib/libc.so.12.220:
>> ldd: /lib/libc.so.12.220: invalid ELF class 2, expected 1
>>
>> It seems that elf32_ldd() fails.
>>
>> Builds of some pkgsrc packages that use gobject
> With this change, ldd /lib/libc.so.12.220 fails under NetBSD/amd64 9.99.101.
>
>
> /lib/libc.so.12.220:
> ldd: /lib/libc.so.12.220: invalid ELF class 2, expected 1
>
> It seems that elf32_ldd() fails.
>
> Builds of some pkgsrc packages that use gobject introspection and meson fails
> because
Hi,
With this change, ldd /lib/libc.so.12.220 fails under NetBSD/amd64 9.99.101.
/lib/libc.so.12.220:
ldd: /lib/libc.so.12.220: invalid ELF class 2, expected 1
It seems that elf32_ldd() fails.
Builds of some pkgsrc packages that use gobject introspection and meson fails
because they uses ldd
Date:Mon, 10 Oct 2022 17:33:35 +
From:"Roland Illig"
Message-ID: <20221010173335.c3cccf...@cvs.netbsd.org>
| Document only the POSIX requirement for now, as I didn't find
| information about _which_ ancient UNIX systems would corrupt the
| filesystem on
In article <20220928163447.b0bf6f...@cvs.netbsd.org>,
Simon J. Gerraty wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: sjg
>Date: Wed Sep 28 16:34:47 UTC 2022
>
>Modified Files:
> src/usr.bin/make: main.c meta.c
>
>Log Message:
>Don't ignore return from snprintf or getcwd
Am 14.08.2022 um 12:14 schrieb Valeriy E. Ushakov:
Module Name:src
Committed By: uwe
Date: Sun Aug 14 10:14:58 UTC 2022
Modified Files:
src/usr.bin/make: make.1
Thanks for your corrections and improvements, now that I see them they
are obvious. :)
Roland
On Sat, Jun 18, 2022 at 02:19:07 +, David H. Gutteridge wrote:
> Module Name: src
> Committed By: gutteridge
> Date: Sat Jun 18 02:19:07 UTC 2022
>
> Modified Files:
> src/usr.bin/man: man.conf.5
>
> Log Message:
> man.conf.5: add details about the machine line and search
Am 10.03.2022 um 22:48 schrieb David H. Gutteridge:
Module Name:src
Committed By: rillig
Date: Tue Mar 8 23:13:05 UTC 2022
Modified Files:
src/usr.bin/man: man.c
Log Message:
man: remove unused global variable 'instype' (since yesterday)
No functional change.
To
> Module Name:src
> Committed By: rillig
> Date: Tue Mar 8 23:13:05 UTC 2022
>
> Modified Files:
> src/usr.bin/man: man.c
>
> Log Message:
> man: remove unused global variable 'instype' (since yesterday)
>
> No functional change.
>
>
> To generate a diff of this
"Roland Illig" writes:
> Module Name: src
> Committed By: rillig
> Date: Sun Feb 27 19:00:46 UTC 2022
>
> Modified Files:
> src/usr.bin/vmstat: vmstat.c
>
> Log Message:
> vmstat: unexport file-scope variable numdisks
>
> There is no need to make this variable externally visible.
Roland Illig writes:
> Am 09.02.2022 um 08:34 schrieb matthew green:
> > Module Name:src
> > Committed By: mrg
> > Date: Wed Feb 9 07:34:18 UTC 2022
> >
> > Modified Files:
> > src/usr.bin/vmstat: vmstat.c
> >
> > Log Message:
> > allow the number of disks
Am 09.02.2022 um 08:34 schrieb matthew green:
Module Name:src
Committed By: mrg
Date: Wed Feb 9 07:34:18 UTC 2022
Modified Files:
src/usr.bin/vmstat: vmstat.c
Log Message:
allow the number of disks displayed in the default output
to be controlled.
To generate a diff
> On Jan 30, 2022, at 2:41 PM, Roland Illig wrote:
>
> Am 30.01.2022 um 14:21 schrieb Christos Zoulas:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Jan 30 13:21:09 UTC 2022
>>
>> Modified Files:
>> src/usr.bin/make: dir.c job.c make.h
>>
>> Log
Am 30.01.2022 um 20:54 schrieb Christos Zoulas:
On Jan 30, 2022, at 2:41 PM, Roland Illig mailto:roland.il...@gmx.de>> wrote:
Am 30.01.2022 um 14:21 schrieb Christos Zoulas:
Module Name:src
Committed By:christos
Date:Sun Jan 30 13:21:09 UTC 2022
Modified Files:
src/usr.bin/make: dir.c job.c
On Sun, 30 Jan 2022 14:54:25 -0500, Christos Zoulas writes:
>> Since usr.bin/make is also used in tools/make, it needs to follow the
>> rules in tools/README, which say that all tools should stick to C89.
>> The format specifier %zu comes from C99 though.
>
>Yes, %zu is annoying because windows
Am 30.01.2022 um 14:21 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Sun Jan 30 13:21:09 UTC 2022
Modified Files:
src/usr.bin/make: dir.c job.c make.h
Log Message:
Make the GNode lineno unsigned to fix lint warning in var.c calling
Am 09.01.2022 um 23:04 schrieb Joerg Sonnenberger:
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Fri Jan 7 20:04:49 UTC 2022
Modified Files:
src/usr.bin/make: for.c
Log Message:
make: use simpler code for
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
> Module Name: src
> Committed By: rillig
> Date: Fri Jan 7 20:04:49 UTC 2022
>
> Modified Files:
> src/usr.bin/make: for.c
>
> Log Message:
> make: use simpler code for handling .for loops
This seems backwards to me.
On Sun, Jan 09, 2022 at 01:18:32AM +0100, Roland Illig wrote:
> If I were to extract the newly added code into a function call
> cpp_skip_string(, varname), would that help? That function could be
> used in var.c as well, for example in ModMatch and ModMatchEq.
Yes, it should be a utility
Am 08.01.2022 um 23:54 schrieb nia:
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
Using memcmp for comparing the variable name was probably overkill since
the variable names are usually very short, so rather compare them byte
by byte.
I don't see the point of this change - it
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
> Using memcmp for comparing the variable name was probably overkill since
> the variable names are usually very short, so rather compare them byte
> by byte.
I don't see the point of this change - it makes the code harder to
read. We
Date:Fri, 10 Dec 2021 01:36:10 +0100 (GMT+01:00)
From:Roland Illig
Message-ID:
| I guess there's really no way around running the whole build before each
| commit, to reach a build success rate of 99.9 %.
What I tend to do, where possible, is make a bunch of
10.12.2021 01:07:22 Robert Elz :
> Date: Thu, 9 Dec 2021 22:25:58 +
> From: "Roland Illig"
> Message-ID: <20211209222558.cdf22f...@cvs.netbsd.org>
> | No functional change.
>
> That obviously wasn't true. That means that you just guessed at that,
I cannot
Date:Thu, 9 Dec 2021 23:57:19 +
From:"Roland Illig"
Message-ID: <20211209235719.cde20f...@cvs.netbsd.org>
| Log Message:
| tests/make: prevent the bug from cond.c 1.283 from happening again
This new test (while OK of itself) would not have done that.
I
Date:Thu, 9 Dec 2021 22:25:58 +
From:"Roland Illig"
Message-ID: <20211209222558.cdf22f...@cvs.netbsd.org>
| make: avoid recursion in CondParser_Or
|
| Previously, a long chain of '1 || 1 || 1 || 1 || ...' led to a deep
| recursion. Furhermore, the code
Roland Illig writes:
> Am 09.12.2021 um 21:01 schrieb matthew green:
> > i'm not asking that you make sun2 or vax stuff work, but
> > some of us choose to use jemalloc 100 on all builds and
> > since this is a supported option, i wanted to make sure
> > you were aware of it.
>
> I added back the
Am 09.12.2021 um 21:01 schrieb matthew green:
i'm not asking that you make sun2 or vax stuff work, but
some of us choose to use jemalloc 100 on all builds and
since this is a supported option, i wanted to make sure
you were aware of it.
I added back the support for jemalloc 100, the few extra
Roland Illig writes:
> Am 08.12.2021 um 02:09 schrieb matthew green:
> >> Module Name: src
> >> Committed By: rillig
> >> Date: Sun Dec 5 14:57:36 UTC 2021
> >>
> >> Modified Files:
> >>src/usr.bin/make: test-variants.sh
> >>src/usr.bin/make/unit-tests: Makefile
Am 08.12.2021 um 02:09 schrieb matthew green:
Module Name:src
Committed By: rillig
Date: Sun Dec 5 14:57:36 UTC 2021
Modified Files:
src/usr.bin/make: test-variants.sh
src/usr.bin/make/unit-tests: Makefile export.mk opt-file.mk
Log Message:
tests/make: migrate
> Module Name: src
> Committed By: rillig
> Date: Sun Dec 5 14:57:36 UTC 2021
>
> Modified Files:
> src/usr.bin/make: test-variants.sh
> src/usr.bin/make/unit-tests: Makefile export.mk opt-file.mk
>
> Log Message:
> tests/make: migrate to jemalloc > 100
note that the build
Am 07.12.2021 um 20:59 schrieb Valery Ushakov:
On Tue, Dec 07, 2021 at 19:28:19 +, Roland Illig wrote:
Removed Files:
src/usr.bin/m4/PSD.doc: Makefile
Log Message:
m4: remove PSD.doc
make: don't know how to make m4.ms. Stop
[...] the proper thing to do is to import it - which I
On Tue, Dec 07, 2021 at 21:37:35 +0100, Roland Illig wrote:
> Am 07.12.2021 um 20:59 schrieb Valery Ushakov:
>
> > If the point you wanted to make with this inarticulate statement was
> > that we don't have m4.ms imported, then the proper thing to do is to
> > import it
>
> Is there a way I could
Am 07.12.2021 um 20:59 schrieb Valery Ushakov:
On Tue, Dec 07, 2021 at 19:28:19 +, Roland Illig wrote:
Removed Files:
src/usr.bin/m4/PSD.doc: Makefile
Log Message:
m4: remove PSD.doc
make: don't know how to make m4.ms. Stop
That was uncalled for... The cited reason is bogus
On Tue, Dec 07, 2021 at 19:28:19 +, Roland Illig wrote:
> Removed Files:
> src/usr.bin/m4/PSD.doc: Makefile
>
> Log Message:
> m4: remove PSD.doc
>
> make: don't know how to make m4.ms. Stop
That was uncalled for... The cited reason is bogus b/c we don't
descend into this directory,
Hey Roland - friendly question:
I saw this error earlier today and threw in a temporary local fix where I
pushed the “const” qualifier deeper (into findcc.[ch]) rather than relax it
in mk dep.c. You choose the other route. Did you do that because you expect
to have that storage r/w, or something
Am 20.08.2021 um 03:12 schrieb Robert Elz:
> Date:Thu, 19 Aug 2021 21:21:04 +
> From:"Roland Illig"
> Message-ID: <20210819212104.7c965f...@cvs.netbsd.org>
>
> | mkdep: fix prototype of findcc
>
> That broke the build.
I'm sorry for that. I knew that mkdep and
Date:Thu, 19 Aug 2021 21:21:04 +
From:"Roland Illig"
Message-ID: <20210819212104.7c965f...@cvs.netbsd.org>
| mkdep: fix prototype of findcc
That broke the build.
| A function that modifies a string argument must not declare that
| argument as 'const char
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
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,
Robert Elz wrote:
> Date:Fri, 2 Apr 2021 06:31:53 +
> From:"Simon Burge"
> Message-ID: <20210402063153.773c7f...@cvs.netbsd.org>
>
> | Add an XXX reminder to convert at(1) to use parsedate(3) in .
>
> If that's intended as an optional facility (at -d ... or
Date:Fri, 2 Apr 2021 06:31:53 +
From:"Simon Burge"
Message-ID: <20210402063153.773c7f...@cvs.netbsd.org>
| Add an XXX reminder to convert at(1) to use parsedate(3) in .
If that's intended as an optional facility (at -d ... or something),
then fine, but please
In article ,
John Klos wrote:
>Log Message:
>Use the same options like m4 (-g turns on GNU, -G turns off GNU) Suggested
>by uwe@
>
>It seems, based on comparing netbsd-9 and -current, that the default was
>-g (GNU on), and is now -G (GNU off). Should the default be mentioned in
>the man page?
Log Message:
Use the same options like m4 (-g turns on GNU, -G turns off GNU) Suggested
by uwe@
It seems, based on comparing netbsd-9 and -current, that the default was
-g (GNU on), and is now -G (GNU off). Should the default be mentioned in
the man page?
John
On 27/03/2021 21:59, Christos Zoulas wrote:
In article <12312.1616877...@splode.eterna.com.au>,
matthew green wrote:
Sounds good. Will it mean that the following code is also preferred to
use parentheses? I like the simplicity without the parentheses, but for
consistency and simplicity of
In article <12312.1616877...@splode.eterna.com.au>,
matthew green wrote:
>> Sounds good. Will it mean that the following code is also preferred to
>> use parentheses? I like the simplicity without the parentheses, but for
>> consistency and simplicity of the rule set, I'd also accept the
>>
> Sounds good. Will it mean that the following code is also preferred to
> use parentheses? I like the simplicity without the parentheses, but for
> consistency and simplicity of the rule set, I'd also accept the
> parenthesized version.
>
> snprintf(buf, sizeof buf, "%s%s", arg1, arg2);
> On Mar 27, 2021, at 8:51 AM, Roland Illig wrote:
>
> On 27.03.2021 08:59, Christos Zoulas wrote:
>> I think we should document we prefer the parenthesized version in style
>> and call it a day.
>
> Sounds good. Will it mean that the following code is also preferred to
> use parentheses? I
On 27.03.2021 08:59, Christos Zoulas wrote:
I think we should document we prefer the parenthesized version in style
and call it a day.
Sounds good. Will it mean that the following code is also preferred to
use parentheses? I like the simplicity without the parentheses, but for
consistency
In article ,
Valery Ushakov wrote:
>On Sat, Mar 27, 2021 at 01:44:07 +0100, Roland Illig wrote:
>
>> On 27.03.2021 00:16, Valery Ushakov wrote:
>> > On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
>> > > To me, writing 'sizeof expr' is clearer than 'sizeof(expr)' since
>> > >
On Sat, Mar 27, 2021 at 01:44:07 +0100, Roland Illig wrote:
> On 27.03.2021 00:16, Valery Ushakov wrote:
> > On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
> > > To me, writing 'sizeof expr' is clearer than 'sizeof(expr)' since
> > > 'sizeof' is not a function, same as with 'return'.
On 27.03.2021 00:16, Valery Ushakov wrote:
On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
To me, writing 'sizeof expr' is clearer than 'sizeof(expr)' since
'sizeof' is not a function, same as with 'return'.
Did I misinterpret the style guide in this regard?
We do want it to look
>
> There are several forms of writing sizeof:
>
> 1. sizeof expr
> 2. sizeof(expr)
> 3. sizeof (expr)
> 4. sizeof(type)
> 5. sizeof (type)
>
> I thought that the point of the rule you cited was to discourage forms 3
> and 5. Does the rule also discourage form 1, and if so, why?
>
> To me,
On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
> > > Log Message:
> > > lint: in malloc calls, use 'sizeof *ptr' instead of 'sizeof(type)'
> >
> > style says "sizeof(" not "sizeof "
> >
> > * Casts and sizeof's are not followed by a space.
>
> There are several forms of
On 26.03.2021 23:18, Christos Zoulas wrote:
In article <20210326203108.3a4e5f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Fri Mar 26 20:31:07 UTC 2021
Modified Files:
src/usr.bin/xlint/common: tyname.c
In article <20210326203108.3a4e5f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 26 20:31:07 UTC 2021
>
>Modified Files:
> src/usr.bin/xlint/common: tyname.c
> src/usr.bin/xlint/lint1: cgram.y decl.c err.c
In article ,
Valery Ushakov wrote:
>On Thu, Mar 11, 2021 at 10:15:05 -0500, Christos Zoulas wrote:
>
>> Module Name: src
>> Committed By:christos
>> Date:Thu Mar 11 15:15:05 UTC 2021
>>
>> Modified Files:
>> src/usr.bin/sed: main.c sed.1
>>
>> Log Message:
>> Add
On Thu, Mar 11, 2021 at 10:15:05 -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Mar 11 15:15:05 UTC 2021
>
> Modified Files:
> src/usr.bin/sed: main.c sed.1
>
> Log Message:
> Add -G to support GNU extensions
This is inverse of m4(1) where
On Sun 28 Feb 2021 at 09:04:28 +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Sun Feb 28 09:04:28 UTC 2021
>
> Modified Files:
> src/usr.bin/resize: Makefile
>
> Log Message:
> disable the rule to copy resize.c since it fails on r/o src trees:
>
> cp:
On 27.01.2021 20:54, Reinoud Zandijk wrote:
Hi,
On Tue, Jan 26, 2021 at 11:44:56PM +, Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Tue Jan 26 23:44:56 UTC 2021
Modified Files:
src/usr.bin/make: parse.c
src/usr.bin/make/unit-tests:
Hi,
On Tue, Jan 26, 2021 at 11:44:56PM +, Roland Illig wrote:
> Module Name: src
> Committed By: rillig
> Date: Tue Jan 26 23:44:56 UTC 2021
>
> Modified Files:
> src/usr.bin/make: parse.c
> src/usr.bin/make/unit-tests: include-main.exp include-subsub.mk
>
> Log
On Tue, Jan 26, 2021 at 11:39:52PM +0100, Roland Illig wrote:
> The code of usr.bin/make gets distributed to a wider audience by Simon's
> bmake distribution (http://www.crufty.net/help/sjg/bmake.html), that's
> where the requirement of supporting C89 compilers comes from. At the
> time I
On 26.01.2021 21:04, Christos Zoulas wrote:
Yes, and I did not push for it for the exact reasons stated below:
There was only a handful of cases and those can be handled with casts or a
macro for now.
I am questioning though the utility of maintaining compatibility with platforms
that
do not
Yes, and I did not push for it for the exact reasons stated below:
There was only a handful of cases and those can be handled with casts or a
macro for now.
I am questioning though the utility of maintaining compatibility with platforms
that
do not support C99 20 years later, vs. using %u and
On 26.01.2021 11:19, Rin Okuyama wrote:
Ping?
I don't think this is correct fix either.
Can you please revert this commit?
Sorry, I didn't get the first mail from Christos back in December,
that's why I didn't take any action.
Why shouldn't the fix I did be correct? I carefully checked the
Ping?
I don't think this is correct fix either.
Can you please revert this commit?
Thanks,
rin
On 2020/12/15 7:57, Christos Zoulas wrote:
In article <20201213212746.3cfc3f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Sun Dec
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
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
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
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
1 - 100 of 486 matches
Mail list logo
