> [...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
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.
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
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
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
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
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
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
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
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,
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
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
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
> 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,
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
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
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
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,
22 matches
Mail list logo
