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
11 matches
Mail list logo
