Re: Proposal: remove usr.bin/mkstr
> [...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 shipped anything called mkstr until I saw this thread. > therefore it should be removed. I have experimented with it and find that what it actually does is not what the manpage led me to think it does - though I can see a close enough relation that I think I could write an accurate manpage. If it is not in fact in live use, what NetBSD does with it matters somewhere between "very little" and "not at all". If it is in fact in live use, someone obviously has found a use for it despite its various string-mangling bugs and misleading documentation. If this call were mine to make? I would add a few lines to mkstr to print a message to stderr, maybe something along the lines of NetBSD is considering removing mkstr; please contact tech-userlevel@netbsd.org if you would like to see it maintained. To suppress this message in the meantime, set MKSTR_SUPPRESS_MESSAGE in the environment. Then, after a couple of releases, and of course assuming nobody squawks, dump it. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: remove usr.bin/mkstr
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.
https://netbsd.org/about/ says:
> NetBSD was originally released in 1993. Over time, its code
> has found its way into many surprising environments, on the
> basis of a long history of quality, cleanliness, and stability.
> The NetBSD code was originally derived from 4.4BSD Lite2 from
> the University of California, Berkeley.
From the features in the above list, mkstr violates the "quality" since
it breaks lots of valid C code:
Code that contains 'perror("string")' or 'yyerror("string")' is
transformed into 'perror(123)' or 'yyerror(123)', which is simply wrong.
In \x escapes in string literals, the backslash is silently removed.
In octal escapes in string literals, each octal escape that starts with
\0 is interpreted as the actual \0, so \007 is "\0""07", and \033
becomes "\0""33". Of course, since the string ends at the first \0, the
"33" does not get written to the message file.
In octal escapes in string literals that start with a digit other than
'0', mkstr messes up the first digit by shifting it 10 places to the
left, which is obviously wrong. It should rather be 6 places.
In concatenated string literals, only the first string literal is
retained, the others are thrown away silently.
Long string literals produce buffer overflows.
Given that mkstr is a simple program of just 320 lines of text, I hope
the above list is enough to convince you that its quality is below any
acceptable limit.
Distributing such crappy programs hurts the reputation of NetBSD
delivering quality software, therefore it should be removed.
Roland
Re: Proposal: remove usr.bin/mkstr
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 here, right? pkgsrc hasn't been required to get it in the past, unless there is a very good reason to change that, it shouldn't be needed in the future. 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. kre
Re: Proposal: remove usr.bin/mkstr
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 were both big and contained many > error messages. ... and none of those programs exist in NetBSD, so at maximum mkstr is useful in pgksrc.
Re: Proposal: remove usr.bin/mkstr
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 belongs into a museum. For a living system, components should certainly have to justify their continued existance. If all the reasons that can be given are "someone might want to use it" and that's to be our standard, even if there are glaring defects and unnecessary restrictions in the tool, any further debate becomes meritless. Joerg
Re: Proposal: remove usr.bin/mkstr
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 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 were both big and contained many
error messages.
Your comment is akin to saying that lint is useless because it
cannot diagnose problems with /etc/passwd.
Aside from the "save a second of build time" argument, there has still
been no substantive explation at all for why mkstr should be removedo
Just "I think it is useless".
Can we please just stop wasting everyone's time with this?
kre
Re: Proposal: remove usr.bin/mkstr
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 treat
everything that we don't use, and cannot imagine wanting to use, as
being without positive value, and retired it, there'd soon be very
little left.
In general, your argument may hold. But in this specific case, the
manual page of mkstr(1) has been saying for 29 years now that the tool
is basically useless.
Even though I have never used bthset(1), I guess it has some value and I
would never propose to remove it from NetBSD. But in the case of
mkstr(1), things are very different. This tool is useless, it messes up
every program that calls perror("string literal") or yyerror("string").
I still don't see any point in keeping it. It just makes every binary
distribution larger than necessary. Granted, only by a small amount, but
still. We also don't keep and distribute old versions of GCC, just in
case someone relies on some bug in it that has been fixed in a later
version.
Roland
Re: Proposal: remove usr.bin/mkstr
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 that parts of K C are not | supported by the compilers in base and at least 64bit platforms are | going to violently object to a lot of other abuse in the code. gcc2 and gcc3 are still in pkgsrc (I believe). Those old releases (I mean BSD 2, not old gcc) need a lot less as host tools to build than we need today. Someone who wanted to do that (or is already doing it perhaps) would manage. | A lack of mkstr is the least of your problems. Starting from nothing, probably. But if someone has a working setup already and mkstr suddenly vanishes? Do you know there is none? Not all NetBSD users read any of our mailing lists, simply asked and getting no answers proves nothing. | 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 treat everything that we don't use, and cannot imagine wanting to use, as being without positive value, and retired it, there'd soon be very little left. And: | If someone actually has a use case, it's not hard to | get a copy and package it independently. But that minority can pay the | price. if that's your view, I will start on deleting all kinds of junk, that's much more costly to build and retain than mkstr, and the minority that want them can "pay the price". Personally I don't think that's the direction we should be taking. Unless there's a real demonstrable cost to retaining something - which really means human time consumed, nothing else costs enough to matter (I suppose there might be a few truly huge things which almost no-one uses which we could delete just to avoid the build time and space costs, but that would be rare). And again, just this discussion is costing more in the value of human time than (since it ended being developed anyway) mkstr has ever consumed.I bet that until this discussion started you didn't know it was there? I just did a ls or /usr/bin and I see lots of stuff that I never even knew existed, never even seen a passing reference to many of them, so clearly they're not very useful... Really? kre
Re: Proposal: remove usr.bin/mkstr
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 demonstrate that NetBSD is not being used somewhere to cross-build BSD 2 (2.10 or 2.11 or something) systems? Can you demonstrate that BSD 2 is cross-buildable from any recent NetBSD release? It would strongly surprise me given that parts of K C are not supported by the compilers in base and at least 64bit platforms are going to violently object to a lot of other abuse in the code. A lack of mkstr is the least of your problems. Cross-compilation of 2BSD requires native F/D-float, so it can only be done on a vax. (compiling the 2.11BSD kernel worked when I tried a few years ago). ...but I cannot find any reason anyone would like to do that since compling 2BSD on simh is much faster. Someone should probably ANSIfy the manpage if we are going to keep mkstr. -- R
Re: Proposal: remove usr.bin/mkstr
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 somewhere > to cross-build BSD 2 (2.10 or 2.11 or something) systems? Can you demonstrate that BSD 2 is cross-buildable from any recent NetBSD release? It would strongly surprise me given that parts of K C are not supported by the compilers in base and at least 64bit platforms are going to violently object to a lot of other abuse in the code. A lack of mkstr is the least of your problems. > Once again, unless some real harm (or even just headaches perhaps) > can be shown to keeping this (or anything) it should be retained, > no matter how useless some of us consider it, because we cannot know > that there truly is no-one anywhere using it. It costs disk space and build time. Both might be minimal, but for something without positive value, it matters. I seriously don't get the attachment to useless junk. It's not like we are removing the history of src/usr.bin/mkstr. If someone actually has a use case, it's not hard to get a copy and package it independently. But that minority can pay the price. Joerg
Re: usefulness of lint (was: Re: Proposal: remove usr.bin/mkstr)
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 take far more than the time you've put in (and a ground-up > > restructuring) to become even as useful as lclint or sparse, let alone > > comparable to a state-of-the-art program checker. > > Could you go into the details of what you mean by "ground-up"? The basic > concepts and data types (expression, type, symbol, operator) look > sensible to me. Sure, the memory management is hard to understand at > first, I'm preparing a README file for that. When I looked it over in detail (some years back now) the internal representation seemed entirely inadequate for doing more sophisticated analyses and handling their results. It was far enough back that I don't remember any details, just that I concluded that it didn't seem worth spending time on. But anyway, to do complicated analyses and then track the results you need an intermediate representation you can iterate over easily and also one that you can extend to hold additional discovered information. Looking at lint1.h it still does not seem suitable at all. For one thing it's too close to the concrete syntax; for example, it has type specifiers in it instead of just types. For another thing, declarations don't seem to have statements in them (!?) so it isn't complete in some fashion and/or is limited to handling one a function at a time. (While the latter isn't the end of the world, it means you can't propagate information between functions in the same translation unit unless they appear in the right order, which is a significant limitation.) And it isn't... how shall I say... sturdy. You want a robust framework you can store a lot of arbitrary information in. If you start stuffing large amounts of dataflow results, or extra type annotations in more expressive type systems that you're using to carry extra information (e.g. allowing functions to be polymorphic in const as I mentioned before), or tracking ranges or impossible values or other stuff like that, it will become a mess. None of this is unreasonable; it was never intended to handle the kinds of analysis I'm thinking of and wasn't written with the possibility in mind. But, all the same, it wasn't. Back then (whenever it was) my conclusion was that hacking it up was probably considerably more expensive than starting over; now that you've fixed up some of the more glaring problems that might be less true (that is, the infrastructure that one might salvage at least works now), but it's still a huge job. > > It used to be that lint did not do this in a useful way (via > > quantifier polymorphism) -- have you improved it? > > Yes, but not in a general way. I just listed the few affected functions > explicitly. See > https://nxr.netbsd.org/search?q=%22effectively+discards%22 for the > implementation, the test msg_346.c contains a few examples. Right. I was talking about doing it in a general way :-) (To do that what you basically want is abstract interpretation over the domain "is const", "is not const", "can be either", and "don't know"; and then in support of that you want your types to be able to express functions where the return constness is covariant in one of the args's constness. And then to do the analogous thing with volatile, though since volatile's a lot less common it's less interesting.) > > I tried to check but running lint on a test file spews fatal errors > > trying to read the system headers. If one adds -Ac11 and > > -D'__attribute__(x)=' to avoid these, it does not complain about your > > example, let alone any other more complex ones. > > Oh, I can see how lint's default settings result in a bad first-time > experience. Ideally, lint should just work out of the box, without even > having to read the manual. The minimal lint flags to make it usable are > currently -g for GCC mode and -S for C99 mode. That's what I use in the > unit tests as well. I'll try to improve the default settings to be more > user-friendly. Yeah, the alphabet soup of options is hard to wade through too. With -g -S it runs but doesn't complain on your example (or one where the first arg is explicitly const char *, either) -- I assume that there's some other flag that needs to be set to enable the warning, but the only thing I see in the man page is an option for _disabling_ warnings by number. :-| Might be nice to add an EXAMPLES section in the man page :-| -- David A. Holland dholl...@netbsd.org
Re: Proposal: remove usr.bin/mkstr
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, unless some real harm (or even just headaches perhaps) can be shown to keeping this (or anything) it should be retained, no matter how useless some of us consider it, because we cannot know that there truly is no-one anywhere using it. kre
Re: usefulness of lint (was: Re: Proposal: remove usr.bin/mkstr)
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. If being old and no longer very useful
> > is the test, then lint should go too. Perhaps so should I.
>
> Do you know of any C compiler that [...]
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 take far more than the time you've put in (and a ground-up
restructuring) to become even as useful as lclint or sparse, let alone
comparable to a state-of-the-art program checker.
Could you go into the details of what you mean by "ground-up"? The basic
concepts and data types (expression, type, symbol, operator) look
sensible to me. Sure, the memory management is hard to understand at
first, I'm preparing a README file for that.
Here's a broad summary of what I changed in lint:
I started working on lint when it couldn't parse a simple C99-style
initialization. That works now.
I added "strict bool mode", in which bool is not an arithmetic type
anymore, making any implicit conversion between arithmetic types and
bool illegal. This mode helps in migrating a program from the
traditional 'int flag' to the more restricted 'bool flag', which
expresses the actual intention of the code in a clearer way. Adding this
mode was quite simple, which made me trust the codebase enough to
continue working on it.
I added a check for the functions from since GCC's diagnostic
about "array subscript has type char" is far away from anything actionable.
I added a check for getopt consistency (see msg_338.c and msg_339.c).
I improved the existing messages by adding more details, such as the
involved types, making them more self-contained, especially in the
presence of deeply nested macros. Oh, and stack traces when the error is
in a deeply nested included file.
For implementation details, I unabbreviated most of the function names
since they contained unnecessary contractions and abbreviations. I fixed
the C grammar to allow for more constructs from C99 and later, thereby
improving the framework to add future custom checks. While there, I
fixed several bugs, I cannot remember them all. If you are interested in
details, search for "from 20" in tests/usr.bin/xlint. Due to the many
new tests I wrote, adding new features or fixing bugs greatly reduces
the danger of accidentally introducing new bugs.
All in all, I mostly trust the code to work well and I think it provides
a solid base.
> Do you know of any C compiler that catches the implicit unconst cast in
> strstr("literal", "lit")[0] = 'X'?
It used to be that lint did not do this in a useful way (via
quantifier polymorphism) -- have you improved it?
Yes, but not in a general way. I just listed the few affected functions
explicitly. See
https://nxr.netbsd.org/search?q=%22effectively+discards%22 for the
implementation, the test msg_346.c contains a few examples.
I tried to check but running lint on a test file spews fatal errors
trying to read the system headers. If one adds -Ac11 and
-D'__attribute__(x)=' to avoid these, it does not complain about your
example, let alone any other more complex ones.
Oh, I can see how lint's default settings result in a bad first-time
experience. Ideally, lint should just work out of the box, without even
having to read the manual. The minimal lint flags to make it usable are
currently -g for GCC mode and -S for C99 mode. That's what I use in the
unit tests as well. I'll try to improve the default settings to be more
user-friendly.
Roland
Re: Proposal: remove usr.bin/mkstr
> [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 and whether that thing is now out of service (which I'm not convinced the PDP-11 is, wholly) are of minor import compared to its current utility, I would say. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: remove usr.bin/mkstr
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 test, then lint should go too. Perhaps so should I.
>
> Do you know of any C compiler that [...]
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 take far more than the time you've put in (and a ground-up
restructuring) to become even as useful as lclint or sparse, let alone
comparable to a state-of-the-art program checker.
> Do you know of any C compiler that catches the implicit unconst cast in
> strstr("literal", "lit")[0] = 'X'?
It used to be that lint did not do this in a useful way (via
quantifier polymorphism) -- have you improved it?
I tried to check but running lint on a test file spews fatal errors
trying to read the system headers. If one adds -Ac11 and
-D'__attribute__(x)=' to avoid these, it does not complain about your
example, let alone any other more complex ones.
--
David A. Holland
dholl...@netbsd.org
Re: Proposal: remove usr.bin/mkstr
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 ago. We have better mechanisms at hand that serve the same purpose (message catalogs, for example). It is not used. It very likely fails in fun way on real world programs. Sorry, but while I can see a point for moving it to src-museum, wtf is this still being installed on most NetBSD systems? Joerg
Re: Proposal: remove usr.bin/mkstr
> 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, request assistance, > from which sometimes the solution might be to simply remove the > roadblock -- other times a suitable alternative might be found. > But while it is doing no harm, leave it alone. +1 I’m definitely guilty of asking for things to be removed, but in the case of my suggestions, it’s because their presence were actual impediments to progress (e.g. keeping round the Token Ring and FDDI code, which no one had apparently used in many years, was impeding progress on network stack improvements). I’m all for keeping old stuff around. -- thorpej
Re: Proposal: remove usr.bin/mkstr
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 composed of many | independent modules, each having its own coding style and a different | upstream author. Probably. | I doubt that each of these projects would use NetBSD's | mkstr to extract the few string literals that might bloat the code. No, they probably wouldn't. But nor will they probably care about 32 bit cpu support at all, everything new (for the general computing market) is 64 bit. Caring in general about 32 bit in a few more years is likely to be just about as common as caring about 16 bit cpus is today. If we want to keep supporting the 32 bit systems we currently support (or at least some of them) someone here is likely going to need to do the work to shrink things to fit. That is when they are needed. Whether mkstr will ever be useful to assist with that I have no idea, but I believe that it is not costing us anything to wait and find out. If it is ever needed, it might perhaps require updates, but those will then be justified by the benefits presumably obtained. Until then it just sits there, harming nothing. | 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. Unless you have gained the ability to predict the future, you do not know that. Proposals to remove anything are likely to be controversial. If there is some obvious benefit to no longer needing to maintain it, like kernel drivers for hardware no-one uses any more, but which keep needing to be updated to compensate for other kernel changes, or applications that are consuming lots of developer time fixing bugs, and have no truly useful benefits, then removal might be justified. But when there is close to zero real benefit, why bother? | Due to the above features, I'd say that lint is still useful. Perhaps. It is a matter of opinion ... but I am not suggesting that we remove it, or anything else. lint however is clearly consuming developer time (yours mostly, but also everyone else who follows src-changes@) so a case for removing that could be made, retaining it has costs. As best I can tell, mkstr has none. | In contrast, mkstr is a very naive program that destroys any | source code using perror or yyerror. By all means, fix the Makefikes for all those programs that are being destroyed by using mkstr to not use it. You would need to do that anyway if you remove mkstr. Be sure to let us know which those are. | This has probably gone unnoticed since nobody | ever tried to use mkstr in any productive way. Using mkstr needs a properly constructed program, it never was intended to simply be applied to any random code. It allows (allowed) the source that needed it to be written and maintained in a reasonable way, while extracting string data from the binary into a file from which the strings required were read, used, and discarded, as needed. Since we abandoned 16 bit cpu support, and haven't yet really reached 32 bit limits much yet, there's been no need. | 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. Further, in the past day this (short) discussion has almost certainly used more developer time than mkstr has consumed in the past decade. Why? 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, request assistance, from which sometimes the solution might be to simply remove the roadblock -- other times a suitable alternative might be found. But while it is doing no harm, leave it alone. kre
Re: Proposal: remove usr.bin/mkstr
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) and xstr(1) ever been used for localization? Because putting the literal strings in a separate file is one simple way to be able to switch messages depending on locales; this may still be---with some adaptation---a use case. BTW---and for an historical note---D.E. Knuth's TANGLE program (used for generating the Pascal code for the TeX programs WEB source files) uses this technique and it is indeed one possibility to localize the message for the TeX user (except for a few messages that may be used before loading this catalog specially if the loading eventually fails). Best, -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Proposal: remove usr.bin/mkstr
> 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-field-initializers -Wno-pointer-sign
-Wno-format-zero-length (probably not all necessary) does:
% cat z.c
#include
extern int foo(char);
int foo(char x)
{
return(isspace(x));
}
% wgcc -c z.c
z.c: In function 'foo':
"z.c", line 5: warning: array subscript has type 'char'
%
(wgcc is a script of mine that, as used there, runs gcc with those
options). Could the warning be more explicit? Probably. But it is a
warning, and after running into one or two instances of it, it is
easily recognizable as being what it is. It certainly is useful to me
in that it catches such mistakes when I make them.
As for your other challenges, I don't know. I don't use bool, I don't
use getopt, and I have never tried anything like your strstr example,
so I am not competent to speak to those (the strstr one is really an
artifact of a botch in strstr's API, semi-compelled by C's design) -
though I have one remark on your bool item:
> Do you know of any C compiler that can treat bool as a separate data
> type from int, [...]
Any C compiler that implements C99 (or, presumably later) _must_ treat
_Bool[%] as a separate data type, because it has some very special:
semantics:
[#1] When any scalar value is converted to _Bool, the result
is 0 if the value compares equal to 0; otherwise, the result
is 1.
so "flag = 2" is, by definition, formally equivalent to "flag = 1" if
flag is a _Bool. (This has no bearing on whether a warning is or isn't
produced; compilers may warn about anything they please. Just that
_Bool _must_ be a separate data type.)
[%] Which is what bool is canonically typedeffed as when writing for a
C version that has _Bool.
> Due to the above features, I'd say that lint is still useful.
I do not find it so. In my experience, lint produces so many useless
warnings that it is mind-numbing to find the tiny signal hiding among
the barrage of noise - if indeed the signal is even there. I find gcc
with the above list of warning options far more useful. (It does
produce some noise, but little enough to be useful anyway.)
Perhaps this is an artifact of how I tend to code.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: remove usr.bin/mkstr
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.
It is no longer really required for anything, or not right now,
but we really are not very far away from exceeding 32 bit limits
for some applications, if that has not already happened.
I don't get how mkstr or a similar tool could help in such a situation.
An application that exceeds 32 bit limits is probably composed of many
independent modules, each having its own coding style and a different
upstream author. I doubt that each of these projects would use NetBSD's
mkstr to extract the few string literals that might bloat the code.
If we plan on retaining support for 32 bit systems, we might need
all the help we can get sometime not very far into the future, and
this tool just might be sometimes helpful.
mkstr is written in a rather naive way. Its most complex part is the
lexer for C-style strings, and that code is also available in
usr.bin/indent and usr.bin/lint.
But even if not, I'd prefer to keep it. It isn't as if it is
costing anything that matters - just leave it alone, resist the
temptation to attempt to improve it or turn it into modern code,
and mostly ignore it. Keeping it shows that we are not ashamed
of our heritage, we came from BSD and still retain some of its
most ancient relics.
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.
I also kind of like having a man page with a Dd line from 1993,
and not just because it wasn't updated when it should have been.
true(1) is even from 1991, which makes mkstr(1) redundant to achieve
this goal.
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 test, then lint should go too. Perhaps so should I.
Do you know of any C compiler that can treat bool as a separate data
type from int, to catch accidental assignments to 'flag = 2' and to help
write the code in a way that is easier to read for humans?
Do you know of any C compiler that complains in a helpful way when
someone calls isspace(char)?
Do you know of any C compiler that checks that the getopt options string
matches the switch statement?
Do you know of any C compiler that catches the implicit unconst cast in
strstr("literal", "lit")[0] = 'X'?
Due to the above features, I'd say that lint is still useful. In
contrast, mkstr is a very naive program that destroys any source code
using perror or yyerror. This has probably gone unnoticed since nobody
ever tried to use mkstr in any productive way. Therefore I don't see any
reason to keep it.
Roland
Re: Proposal: remove usr.bin/mkstr
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 not right now, but we really are not very far away from exceeding 32 bit limits for some applications, if that has not already happened. If we plan on retaining support for 32 bit systems, we might need all the help we can get sometime not very far into the future, and this tool just might be sometimes helpful. But even if not, I'd prefer to keep it. It isn't as if it is costing anything that matters - just leave it alone, resist the temptation to attempt to improve it or turn it into modern code, and mostly ignore it. Keeping it shows that we are not ashamed of our heritage, we came from BSD and still retain some of its most ancient relics. I also kind of like having a man page with a Dd line from 1993, and not just because it wasn't updated when it should have been. Pity that we don't support pi/px as well. | While looking at these programs, you may want to retire xstr as well. | It's also a pdp-11 artifact. It originated from that era ... so did ex/vi ... but was still widely used with 32 bit systems. xstr is no longer used (or not much) because compilers have mostky started duplicating its functionality. 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 test, then lint should go too. Perhaps so should I. kre
Proposal: remove usr.bin/mkstr
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
