Am 21.12.2024 um 20:21 schrieb tlaro...@kergis.com:
> Problem found: NetBSD's flex doesn't understand the idiom but is used,
> while (pkgsrc) flex-2.6.4 is able to interpret such regex.
>
> Nonetheless, has someone information about the handling of negative
> chars in a regex (there are discussions
Am 25.11.2024 um 17:26 schrieb Edgar Fuß:
> Why does C's sizeof operator need parentheses when applied to a type?
>
> I suspect some ambiguity without the parentheses, but I fail do make up one.
The expression 'sizeof int * + 1' has two different interpretations:
sizeof(int) * (+1)
sizeof(int *)
Am 03.11.2024 um 00:52 schrieb Robert Elz:
> Date:Sat, 2 Nov 2024 22:36:10 +0100
> From: Roland Illig
>
> | Is the "- 0" in the first expression really necessary? If so, for which
> | cases?
>
> When _POSIX_C_SOURCE is undefined (or def
In the system headers, we use this pattern a lot:
> #if (_POSIX_C_SOURCE - 0 >= 200809L) || defined(_NETBSD_SOURCE)
Are the parentheses around the first condition really necessary? If so,
for which cases?
Is the "- 0" in the first expression really necessary? If so, for which
cases?
If they aren
Am 20.09.2024 um 14:44 schrieb Greg Troxel:
> Roland Illig writes:
>
>> The first commit demonstrates the buggy state by having a test that
>> technically succeeds but has lots of FIXME comments in all the places
>> that are wrong, already stating what is expected aft
Am 19.09.2024 um 15:20 schrieb Greg Troxel:
> We currently have no remquo test. I've written one, stealing from
> tests/lib/libm/t_sin, and it shows some failing output.
When I'm in such a situation, I usually do a two-commit approach:
The first commit demonstrates the buggy state by having a te
Am 05.07.2024 um 06:36 schrieb Robert Elz:
> In sh, I have a whole set of functions that are called
> via a function pointer in a data struct
>
> (*p->func)(arg);
>
> One of those functions needs a 2nd arg, which means that
> to keep compatible function profiles these days, I need
> to add th
17.05.2024 15:50:06 Edgar Fuß :
>> main: .PHONY
>> make -V X | wc -c
> Wow, I didn't know that worked.
>
> How on earth /does/ it work? If a command happens to be "make", make just
> forks without the child process exec()ing anything, so all the make variables
> etc. are inherited?
No, that w
Am 16.05.2024 um 18:09 schrieb Edgar Fuß:
> Following a discussion (make mdi: shell limit exceeded) on tech-pkg@,
> I keep asking myself whether there's a sensible way to output the
> contents of a make variable to a file (or pipe), even if the contents
> exceeds ARG_MAX.
In usr.bin/make from May
Am 04.05.2024 um 02:27 schrieb Aleksey Cheusov:
> mktemp man pages says the following about mkdtemp(3)
>
> 1) STANDARDS:
>
> The mkstemp() and mkdtemp() functions conform to IEEE Std 1003.1-2004
> (``POSIX.1'') and IEEE Std 1003.1-2008 (``POSIX.1''), respectively.
>
> 2) BUGS:
>
>
In the manual pages, there are several different wordings around errno:
An error code is stored in the external variable "errno".
An error code is stored in the global variable "errno".
An error code is stored in the global "errno".
An error code is stored in "errno".
I'd like to unify all these
Am 28.06.2023 um 12:57 schrieb tlaro...@polynum.com:
> But isn't it incorrect? POSIX 2018 says:
>
> '"\ddd", where ddd is a one, two, or three-digit octal number, shall be
> written as a byte with the numeric value specified by the octal number.'
The main intended takeaway from this sentence is th
Am 17.04.2023 um 02:55 schrieb David Holland:
On Sat, Apr 15, 2023 at 11:47:08AM +0200, Roland Illig wrote:
> Since C90, function prototypes are available. They have become so common
> now that mentioning them is more confusing than helpful. I suggest
> removing these
Hi,
Since C90, function prototypes are available. They have become so common
now that mentioning them is more confusing than helpful. I suggest
removing these two lines:
* Use ANSI function declarations. ANSI function braces look like
* old-style (K&R) function braces.
I don't know what 'A
Hi,
The style guide says:
When declaring variables in functions declare them sorted by size
What is the purpose of this rule, and is it still useful? I'd rather see
the variables grouped by topic. If that rule's purpose is to help some
ancient compiler lay out the variables efficiently, I don'
Am 15.03.2023 um 16:40 schrieb Jason Thorpe:
On Mar 15, 2023, at 4:23 AM, Taylor R Campbell
wrote:
Proposal: Forbid extern declarations in .c files.
extern declarations in .c files invite easily avoided bugs where the
definition and use have mismatched types, because the compiler doesn't
ha
It should be easy to add this check to lint by adding a new message. There are
several recent commits that add a message to lint1/err.c.
Whoever wants to add this check, feel free to do so. For external code and a
few other files, the newly added message will need to be excluded by
"LINTFLAGS+=
Am 22.02.2023 um 05:54 schrieb Mouse:
121$(x:C;^.*\.([0-9].*)$$;$(INSTMANDIR)/cat\1;):
So, I'm wondering, is this a bug in 9.1's make, or am I doing
something wrong here?
TL;DR: There are several cases in which make silently ignores parse
errors, such as '$$' in variable modifi
Am 22.02.2023 um 03:01 schrieb Mouse:
121 $(x:C;^.*\.([0-9].*)$$;$(INSTMANDIR)/cat\1;):
The same code works with 5.2's make (which, of course, says only
moderately little for its correctness...).
So, I'm wondering, is this a bug in 9.1's make, or am I doing something
wrong here?
TL;DR:
Am 03.10.2022 um 14:31 schrieb nia:
This is the current alloca definition in the libc headers:
#if defined(_NETBSD_SOURCE)
#if defined(alloca) && (alloca == __builtin_alloca) && \
According to my knowledge of the C preprocessor, the condition 'alloca
== __builtin_alloca' always evaluates to '0
Am 03.09.2022 um 11:06 schrieb Thomas Klausner:
On Fri, Sep 02, 2022 at 07:08:23PM +0200, Thomas Klausner wrote:
I'd like the change the behaviour to match what GNU grep does.
Since I saw only positive feedback, here's my proposed patch.
Comments?
The patch does not contain a test.
The brac
Am 24.06.2022 um 23:35 schrieb Charlotte Koch:
Hiya,
My inclination is to remove all code from robots(6) that is guarded
inside "#ifdef FANCY" -- because it isn't defined at all in the code nor
the Makefile. And "FANCY" doesn't seem to have any meaning in e.g.
curses, either.
That led me to inv
Am 17.04.2022 um 13:07 schrieb Robert Elz:
And still no-one has provided a single good reason why it should be
removed, nothing better than not seeing a reason to keep it, which is
an entirely different thing. If someone can explain what harm it is
doing, I would probably stop objecting.
http
Am 11.04.2022 um 03:05 schrieb Robert Elz:
| It costs disk space and build time.
That's not worthy of comment.
| for something without positive value,
That's just opinion. That's my point. We cannot know what doesn't
have value. We know what we personally use, if we were to each tre
Am 10.04.2022 um 00:15 schrieb David Holland:
On Sat, Apr 09, 2022 at 03:16:24PM +0200, Roland Illig wrote:
> > That's just like lint - once used all the time, code was not accepted
> > if not lint free, now essentially useless as tge compilers have most
> > of its
Am 09.04.2022 um 12:20 schrieb Robert Elz:
Date:Sat, 9 Apr 2022 10:10:42 +0200
From:Anders Magnusson
Message-ID: <1c33051c-45fe-931b-0159-03136c07e...@tethuvudet.se>
| Besides that, mkstr is quite useless on a 32-bit architecture so
| I would say remove it.
Hi,
Since 1993, the manual page of mkstr(1) has been saying that this tool
should not be used. 29 years later, I'd like to remove this tool from
NetBSD since there is no practical use case for it.
Objections?
Roland
Am 13.01.2022 um 07:48 schrieb Roland Illig:
13.01.2022 04:18:36 Joerg Sonnenberger :
Specific remark here: try to avoid empty structures. They can
create a real hassle when interacting between C and C++ as that's
explicitly invalid for the latter.
Not only that, in standard C they
13.01.2022 04:18:36 Joerg Sonnenberger :
>
> Specific remark here: try to avoid empty structures. They can create a
> real hassle when interacting between C and C++ as that's explicitly
> invalid for the latter.
Not only that, in standard C they are a syntax violation as well (see C11
6.7.2.1)
On 17.03.2021 09:07, Valery Ushakov wrote:
On Wed, Mar 17, 2021 at 00:55:03 +0100, Roland Illig wrote:
Frankly, with modern compilers I don't see much (any, more like) point
of using lint on modern code. Playing catch up with gcc extensions
doesn't add much value compared to gcc/
Hi,
when I run lint with the -t flag for traditional C (which means before
C90), I always get these warnings:
$ >empty.c
$ lint -t empty.c
(1): warning: 'long double' is illegal in traditional C [266]
(1): warning: function prototypes are illegal in traditional C [270]
(2): warning: 'long double
On 06.02.2021 20:58, Roland Illig wrote:
On 05.02.2021 21:12, Roland Illig wrote:
Hi,
when I run sysinst from a boot CD, after pressing Enter 3 times in a
row, I get the screen "You have chosen". This screen presents a menu.
The items of the menu are indented with 16 characters (
On 07.02.2021 05:25, Valery Ushakov wrote:
What's wrong is that for addstr we call _cursesi_addwchar with a
pointer to a dummy variable, but for addch we call it with a pointer
to win->curx, so we first increment win->curx in the nested
_cursesi_addwchar calls (for the spaces) and then we also in
On 05.02.2021 21:12, Roland Illig wrote:
Hi,
when I run sysinst from a boot CD, after pressing Enter 3 times in a
row, I get the screen "You have chosen". This screen presents a menu.
The items of the menu are indented with 16 characters (probably 2 tabs)
relative to the surrou
Hi,
when I run sysinst from a boot CD, after pressing Enter 3 times in a
row, I get the screen "You have chosen". This screen presents a menu.
The items of the menu are indented with 16 characters (probably 2 tabs)
relative to the surrounding text.
When I start sysinst from an installed system
35 matches
Mail list logo
