> [...issues with mkstr...]
> Distributing such crappy programs hurts the reputation of NetBSD
> delivering quality software,
Does it? I have yet to hear of anyone thinking any the less of NetBSD
for including mkstr, excepting any directly derived from this thread.
I was not even aware NetBSD sh
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
Date:Sun, 17 Apr 2022 06:37:14 +
From:nia
Message-ID:
| ... and none of those programs exist in NetBSD, so at maximum
| mkstr is useful in pgksrc.
If it didn't already exist in NetBSD, I would probably agree. But it
does, and backwards compat is important
On Tue, Apr 12, 2022 at 07:19:59AM +0700, Robert Elz wrote:
> Once again you are making assumptions about the way it is used.
> mkstr is only used for particular programs which are designed to
> be used with it, not simply any random source code. Those were ones
> (and one in particular) that wer
Am Tue, Apr 12, 2022 at 07:19:59AM +0700 schrieb Robert Elz:
> Can we please just stop wasting everyone's time with this?
I'm stopping my participation in this thread here, because it has become
completely pointless and frankly, depressing. NetBSD is not a museum,
even if it supports hardware that
Date:Mon, 11 Apr 2022 22:59:15 +0200
From:Roland Illig
Message-ID:
| This tool is useless, it messes up
| every program that calls perror("string literal") or yyerror("string").
Once again you are making assumptions about the way it is used.
mkstr is only used f
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
Date:Sun, 10 Apr 2022 22:03:58 +0200
From:Joerg Sonnenberger
Message-ID:
| Can you demonstrate that BSD 2 is cross-buildable from any recent NetBSD
| release?
I haven't tried, but I have little doubt that it can be done.
| It would strongly surprise me given
Den 2022-04-10 kl. 22:03, skrev Joerg Sonnenberger:
Am Sun, Apr 10, 2022 at 09:30:19PM +0700 schrieb Robert Elz:
Date:Sat, 9 Apr 2022 21:33:36 +0200
From:Joerg Sonnenberger
Message-ID:
| wtf is this still being installed on most NetBSD systems?
Can you demo
Am Sun, Apr 10, 2022 at 09:30:19PM +0700 schrieb Robert Elz:
> Date:Sat, 9 Apr 2022 21:33:36 +0200
> From:Joerg Sonnenberger
> Message-ID:
>
> | wtf is this still being installed on most NetBSD systems?
>
> Can you demonstrate that NetBSD is not being used somewhe
On Sun, Apr 10, 2022 at 01:13:26AM +0200, Roland Illig wrote:
> > We should not remove lint until we have another program checker to
> > replace it with, but it is not itself very useful. And yes, I know
> > you've been working on it and I haven't been following the details,
> > but it will tak
Date:Sat, 9 Apr 2022 21:33:36 +0200
From:Joerg Sonnenberger
Message-ID:
| wtf is this still being installed on most NetBSD systems?
Can you demonstrate that NetBSD is not being used somewhere
to cross-build BSD 2 (2.10 or 2.11 or something) systems?
Once again, u
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 functionality built in.
> [mkstr] is clearly meant as a hack to workaround limitations of an
> architecture that went out of service a quarter decade ago.
More relevant here, I think, is that it is a kludgy way of doing
something that now is commonly done - and done properly - by the
compiler itself. What motivated it a
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 functionality built in. If being old and no longer very useful
> > is the
Am Sat, Apr 09, 2022 at 10:49:55PM +0700 schrieb Robert Elz:
> | Therefore I don't see any reason to keep it.
>
> And I have seen no reason to remove it. Not even a hint of one.
It is clearly meant as a hack to workaround limitations of an
architecture that went out of service a quarter decade
> On Apr 9, 2022, at 8:49 AM, Robert Elz wrote:
> Just stop suggesting removing things for no better reason than
> that you see no point keeping them. If the existence of something
> which seems not to be all that necessary is being a roadblock
> to getting other work done, then by all means, r
Date:Sat, 9 Apr 2022 15:16:24 +0200
From:Roland Illig
Message-ID:
| I don't get how mkstr or a similar tool could help in such a situation.
Nor do I right now, but nor do I know of an immediate need.
| An application that exceeds 32 bit limits is probably compo
Hello,
Le Sat, Apr 09, 2022 at 03:16:24PM +0200, Roland Illig a écrit :
> [About the removal of mkstr]
> [...]
>
> I chose mkstr because I thought it would be uncontroversial, to see
> whether it is possible at all to remove a tool that was useful 30 years
> ago for the last time.
Have mkstr(1)
> Do you know of any C compiler that complains in a helpful way when
> someone calls isspace(char)?
Yes.
The gcc that shipped with 5.2, run with -Werror -W -Wall
-Wpointer-arith -Wcast-qual -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wno-uninitialized -Wno-sign-compare
-Wno-missing-
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.
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.
It is no longer really required for anything, or
Den 2022-04-09 kl. 01:23, skrev Roland Illig:
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.
It doesn't say that it should not be used, it says t
23 matches
Mail list logo
