Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #6888

Re: int * vs char *

Show all headers | View raw

Shao Miller <sha0.miller@gmail.com> writes:
> On 6/22/2011 20:23, Keith Thompson wrote:
>> Shao Miller<sha0.miller@gmail.com>  writes:
>>> On 6/22/2011 2:56 PM, Ian Collins wrote:
>>>> On 06/22/11 10:25 PM, James Kuyper wrote:
>> [...]
>>>> The existing code problem was a acknowledged when C++ changed the type
>>>> of string literals. Compilers may choose not to issues a diagnostic for
>>>> this case. Now we have had over a decade to fix the smelly code, I
>>>> believe a diagnostic is now required by the new C++ standard.
>>>>
>>>> C could and should have done the same, but as usual those worried about
>>>> breaking already broken code appear to have won the day.
>>>>
>>>
>>> Again, why should a C implementation be rendered non-conforming [to some
>>> future Standard] thusly?
>>>
>>> In a "bare metal" environment, one might very well wish to overwrite
>>> their string literals' storage, no?  The "bare metal" implementation
>>> might need to define such action as being appropriate.
>>>
>>> By using "proper" static arrays, we lose out on the "shared storage"
>>> benefit.  Writing for bare metal, hopefully one knows what one is doing.
>>>
>>> Is this example silly?
>>
>> If there's a need for a "bare metal" environment to be able to modify
>> string literals, that can be provided as an extension.
>
> As in, a documented extension?

Well, yes, documenting it would certainly be a nice touch.

>> Any code that
>> currently takes advantage of that ability already has undefined
>> behavior.
>>
>
> Exactly the nature of my question.  If there is at least one real 
> program that depends on this "undefined behaviour" (use the Standard 
> definition, please :) ),

If you were correcting my spelling from "behavior" to "behaviour", the
Standard uses the US-style "behavior" spelling.  If not, what do you
mean?

(Hmm, does the UK standard body, its equivalent of the US ANSI,
"translate" ISO standards into UK spellings?)

>                          then that program's source code might have to 
> be adjusted for future versions of an implementation, depending on how 
> that future implementation implements the extension.
>
>> If such a feature were desirable, we could have an optional 'M' (for
>> modifiable) prefix for string literals, similar to the existing 'L'
>> prefix for wide string literals.  For example, "hello" could be of type
>> const char[6], and M"hello" could be of type char[6]].
>>
>
> An interesting idea!  'M()' could get close, perhaps.
>
>    #define M(string) ((char[]){string})
>
> I guess we'd need 'ML', too?
>
>> The fact that I've never heard of anyone implementing something like
>> this suggests (though not strongly) that there's no demand for it.
>
> Suppose you've a program loaded into memory via a serial line.  Suppose 
> the program is loaded into writable memory (that seems pretty likely). 
> Suppose the program offers a CLI.  Suppose a user can rename commands or 
> variables, or redefine preset scripts.  Yes, all of these could be done 
> cleanly (in my opinion) via 'static' 'char[]'s, but it can be more 
> convenient for some people to simply type the string literal right into 
> some spot in the source code where it's used and forget about coming up 
> with a meaningful (and possibly redundant) identifier, i.e. 
> 'csz_Hello__world___And_how_are_you__today_'

And suppose the user wants to replace the content with a string that's
longer than the original literal.

[snip]

>> In short, I think the issue is not that anyone wants to modify
>> string literals;
>
> For the right use case, I would.

Perhaps.

There are benefits and drawbacks both to allowing modifications of
string literals, and to disallowing them.  IMHO the benefits of
disallowing modifications (catching potential errors) far outweight the
benefit for a few obscure use cases.

My M"..." proposal *could* give us the best of both, and I wouldn't
object if it showed up in a future standard.  I just don't think
it's sufficiently useful.

>> it's that making them const would break existing
>> code that *doesn't* actually modify string literals.
>>
>> (Stroustrup was able to do this in C++ because there was no existing
>> C++ code before he invented the language.)
>
> Well doesn't 'const' "come from" C++, anyway?

I think so.

> And why isn't there a write-only counterpart, for symmetry, such as a 
> memory-mapped port that mustn't be read from?

Lack of usefulness, I suppose.  "const" (which perhaps should have been
called "readonly") is massively useful.  "writeonly" would be probably
useful only in some very low-level code.  And an implementation could
provide a #pragma that does the same thing (have any done so?).

> And during very early development (and Usenet code examples), can it be 
> pleasant to avoid 'const' concerns altogether and then to analyze and 
> refine, gradually sprinkling 'const' in where appropriate?  I don't 
> advocate this, but imagine that some folks might get "stuck" in 
> "analysis paralysis" if they had to think 'const'ness through at every 
> corner.  I could be mistaken.

I think designing const into your code from the start is a lot
easier.

My personal preference is to declare everything "const" *unless*
I specifically need to modify it.  In fact, if I were designing
a new language (without concern for backward compatibility),
declared objects would be read-only by default, with some special
syntax ("var"?) to make them writable.  With sufficiently flexible
initialization, I suspect most objects don't need to be modified
after their creation.  (I do not for one moment suggesting making
such a change to C.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

int * vs char * yugandhar <nospam@nospam.com> - 2011-06-21 21:49 +0000
  Re: int * vs char * John Gordon <gordon@panix.com> - 2011-06-21 21:58 +0000
    Re: int * vs char * "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-06-21 20:25 -0400
  Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-22 09:59 +1200
  Re: int * vs char * Ike Naar <ike@sverige.freeshell.org> - 2011-06-21 22:18 +0000
  Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-06-21 18:34 -0500
  Re: int * vs char * Keith Thompson <kst-u@mib.org> - 2011-06-21 15:42 -0700
    Re: int * vs char * Noob <root@127.0.0.1> - 2011-06-22 10:28 +0200
      Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-06-22 05:23 -0500
      Re: int * vs char * James Kuyper <jameskuyper@verizon.net> - 2011-06-22 06:25 -0400
        Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-23 07:56 +1200
          Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-06-22 18:12 -0500
            Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-23 10:23 +1200
            Re: int * vs char * Keith Thompson <kst-u@mib.org> - 2011-06-22 17:23 -0700
              Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-23 12:54 +1200
                Re: int * vs char * Keith Thompson <kst-u@mib.org> - 2011-06-22 18:18 -0700
                Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-23 13:23 +1200
              Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-06-24 15:39 -0400
                Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-25 09:28 +1200
                Re: int * vs char * Keith Thompson <kst-u@mib.org> - 2011-06-24 14:58 -0700
                Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-25 10:06 +1200
                Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-06-26 15:44 -0500
                Re: int * vs char * Keith Thompson <kst-u@mib.org> - 2011-06-24 14:29 -0700
                Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-25 09:36 +1200
                Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-06-26 16:24 -0500
                Re: int * vs char * Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-25 08:39 -0700
            Re: int * vs char * gordonb.5qick@burditt.org (Gordon Burditt) - 2011-06-22 23:49 -0500
      Re: int * vs char * Stephen Sprunk <stephen@sprunk.org> - 2011-06-22 11:31 -0500
        Re: int * vs char * gordonb.idn9q@burditt.org (Gordon Burditt) - 2011-06-23 00:45 -0500
          Re: int * vs char * pacman@kosh.dhis.org (Alan Curry) - 2011-06-23 20:08 +0000
          Re: int * vs char * Stephen Sprunk <stephen@sprunk.org> - 2011-06-23 22:40 -0500
            Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-24 15:46 +1200
              Re: int * vs char * Stephen Sprunk <stephen@sprunk.org> - 2011-06-24 09:24 -0500
                Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-07-04 18:00 -0400
                Re: int * vs char * Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-05 07:45 +0100
                Re: int * vs char * Harald van Dijk <truedfx@gmail.com> - 2011-07-05 10:39 -0700
                Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-07-05 14:09 -0400
                Re: int * vs char * Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-07 21:56 +0300
                Re: int * vs char * Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-08 02:46 +0300
                Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-07-07 22:26 -0400
                Re: int * vs char * Stephen Sprunk <stephen@sprunk.org> - 2011-07-07 22:41 -0500
                Re: int * vs char * "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-07-05 15:32 -0400
                Re: int * vs char * Shao Miller <sha0.miller@gmail.com> - 2011-07-06 09:58 -0400
      Re: int * vs char * Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-23 01:02 -0700
        Re: int * vs char * Ian Collins <ian-news@hotmail.com> - 2011-06-23 20:11 +1200
          Re: int * vs char * Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-25 09:23 -0700
            Re: int * vs char * Keith Thompson <kst-u@mib.org> - 2011-06-25 12:37 -0700
              Re: int * vs char * Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-27 11:40 -0700
  Re: int * vs char * Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-21 21:46 -0400
    Re: int * vs char * "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-22 10:06 -0700
      Re: int * vs char * Keith Thompson <kst-u@mib.org> - 2011-06-22 13:06 -0700
        Re: int * vs char * "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-22 13:29 -0700
  Re: int * vs char * Stephen Sprunk <stephen@sprunk.org> - 2011-06-21 21:29 -0500

csiph-web