friedl@vsi.COM (Stephen J. Friedl) (02/20/89)
Hi.ho folks,
I've a thought on a feature that might be useful in an ANSI
lint and I'd like to bounce this off you folks.
I am postulating that it would be helpful to have a lint
option that make string literals "array of const char" rather
than "array of char" and do type checking on that basis. The
Committee apparently considered this for the language itself but
eventually rejected it (maybe some ANSI-kind-of-people could
comment on this). Perhaps they rejected it because it would have
required that old code be retrofitted with /const/ everywhere,
and they felt this was too high a burden to place on those using
a new compiler.
For new code, however, produced by those who think and use
/const/ all the time (like me) I think this might be a big win to
have lint check for this.
Can anybody find anything wrong with this idea? Discussions
here or via email would be fine.
Steve
--
Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com
V-Systems, Inc. I speak for you only attmail!vsi!friedl
Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl
--------Barbara Bush on... on... No, I just can't do it...--------henry@utzoo.uucp (Henry Spencer) (02/22/89)
In article <1057@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: > I am postulating that it would be helpful to have a lint >option that make string literals "array of const char" rather >than "array of char" and do type checking on that basis... It sounds superficially attractive, but I don't think it would help. All those pointers to const char would end up turning into pointers to char as soon as they got used anywhere anyway, and the type checking would be more of a hindrance than a help. To run down instances of string literals being modified, I'm afraid you need data-flow analysis, and probably fairly sophisticated data-flow analysis. There just is no simple way around the problem. >Committee apparently considered this for the language itself but >eventually rejected it (maybe some ANSI-kind-of-people could >comment on this). Perhaps they rejected it because it would have >required that old code be retrofitted... In general (note this qualifier), X3J11 rejected anything that required that old, legal, clean code be retrofitted. One can argue about the definitions of some of those words, but the intent was clear. There is a basic problem with "const" in that people want it to mean two different things: constant (this really is a constant, which does not change) and read-only (this may be a variable, but *you* are not allowed to change it). Trying to combine the two in one keyword leads to many boobytraps. For example, if const really means constant, then surely casts from (say) "const char *" to "char *" should be illegal? Unfortunately, if it means read-only, such casts are necessary, e.g. to let strchr accept a "const char *" argument and return "char *". At least one of the older drafts did have strings as arrays of const char, but it just caused too many problems. "Const" is trickier than it looks. -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/23/89)
In article <1057@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes:
- I am postulating that it would be helpful to have a lint
-option that make string literals "array of const char" rather
-than "array of char" and do type checking on that basis.
This is basically a good idea, since attempts to modify string
literals are non-portable.
-The Committee apparently considered this for the language itself
-but eventually rejected it (maybe some ANSI-kind-of-people could
-comment on this). Perhaps they rejected it because it would have
-required that old code be retrofitted with /const/ everywhere,
-and they felt this was too high a burden to place on those using
-a new compiler.
No, the main counterargument was that there is a lot of existing
code that depends on the ability to modify string literals (e.g.
mktemp() on UNIX), so compilers for those clientele would best
preserve that property.