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

Groups > comp.lang.c > #3941 > unrolled thread

I need help

Back to article view | Back to comp.lang.c

Contents

  I need help janus <emekamicro@gmail.com> - 2011-05-14 04:05 -0700
    Re: I need help "Heinrich Wolf" <invalid@invalid.invalid> - 2011-05-14 13:30 +0200
      Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-14 13:46 +0200
        Re: I need help "Heinrich Wolf" <invalid@invalid.invalid> - 2011-05-14 14:20 +0200
      Re: I need help Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-14 04:48 -0700
    Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-14 13:39 +0200
      Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-14 13:44 +0200
      Re: I need help "Heinrich Wolf" <invalid@invalid.invalid> - 2011-05-14 14:23 +0200
        Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-16 16:47 +0200
      Re: I need help James Kuyper <jameskuyper@verizon.net> - 2011-05-14 09:14 -0400
        Re: I need help "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-05-16 16:43 +0200
          Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 08:23 -0700
            Re: I need help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 23:00 +0100
              Rationale for Shao Miller <sha0.miller@gmail.com> - 2011-05-16 23:40 -0500
                Re: Rationale for Some of 6.7.3p9? Shao Miller <sha0.miller@gmail.com> - 2011-05-16 23:43 -0500
                  Re: Rationale for Some of 6.7.3p9? Heikki Kallasjoki <see@end.of.message.invalid> - 2011-05-17 06:06 +0000
                    Re: Rationale for Some of 6.7.3p9? Heikki Kallasjoki <see@end.of.message.invalid> - 2011-05-17 06:13 +0000
                      Re: Rationale for Some of 6.7.3p9? Angel <angel+news@spamcop.net> - 2011-05-17 14:03 +0000
                      Re: Rationale for Some of 6.7.3p9? Shao Miller <sha0.miller@gmail.com> - 2011-05-17 10:19 -0400
                Re: Rationale for Ike Naar <ike@iceland.freeshell.org> - 2011-05-17 06:09 +0000
                  Re: Rationale for Shao Miller <sha0.miller@gmail.com> - 2011-05-17 10:20 -0400
    Re: I need help Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-14 04:45 -0700
    Re: I need help Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-14 09:39 -0400
      Re: I need help sandeep <nospam@nospam.com> - 2011-05-15 21:37 +0000
        Re: I need help Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-15 18:35 -0400
          Re: I need help pete <pfiland@mindspring.com> - 2011-05-15 19:45 -0400
            Re: I need help pete <pfiland@mindspring.com> - 2011-05-15 20:15 -0400
          Re: I need help sandeep <nospam@nospam.com> - 2011-05-16 18:27 +0000
            Re: I need help Shao Miller <sha0.miller@gmail.com> - 2011-05-16 14:45 -0400
            Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 11:41 -0700
              Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-16 19:12 +0000
                Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 12:30 -0700
                  Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-16 20:09 +0000
                  Re: I need help sandeep <nospam@nospam.com> - 2011-05-16 20:35 +0000
                    Re: I need help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 23:22 +0100
                      Re: I need help David Thompson <dave.thompson2@verizon.net> - 2011-05-24 01:19 -0400
                Re: I need help Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 00:19 -0700
                  Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-19 14:37 +0000
                    Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-19 08:17 -0700
                      Re: I need help Seebs <usenet-nospam@seebs.net> - 2011-05-19 16:08 +0000
                    Re: I need help Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 11:13 -0700
        Re: I need help Keith Thompson <kst-u@mib.org> - 2011-05-16 08:12 -0700

Page 1 of 3  [1] 2 3  Next page →

#3941 — I need help

Hello All,

I found this is a code I am currently studying, could someone explain it to me.

char * string = "Simulated Annealing = 12847369";
char * value = strchr(string, '=');

*(value ++ ) = 0;


printf("%s ==== %s", value, string);

I noticed that sting will print in a new line, why this?

char* karmarkar = "Karmarkar   958572";
I want to use strchr to find the first occurrence of "space" in string karmarkar.
How do I do that? 

Regards,
Janus
 

[toc] | [next] | [standalone]

#3942

"janus" <emekamicro@gmail.com> schrieb im Newsbeitrag 
news:04ee4fd1-29ef-4640-a906-22055187c1e4@glegroupsg2000goo.googlegroups.com...
> Hello All,
>
> I found this is a code I am currently studying, could someone explain it 
> to me.
>
> char * string = "Simulated Annealing = 12847369";
> char * value = strchr(string, '=');

strchr returns a char* pointing to the '=' within string:

> *(value ++ ) = 0;

I'm not quite sure about the preceedence of operations. But I think,
first '=' is replaced by '\0', thus truncating string. value would then be 
"",
but is advanced with ++ by on character in string, so pointing now to " 
12847369"

> printf("%s ==== %s", value, string);

Using the explanation above I expect it to print
"Simulated Annealing  ====  12847369"

> I noticed that sting will print in a new line, why this?

I do not understand.

> char* karmarkar = "Karmarkar   958572";
> I want to use strchr to find the first occurrence of "space" in string 
> karmarkar.
> How do I do that?

strchr(karmarkar, ' ')

> Regards,
> Janus

kind regards
Heiner 

[toc] | [prev] | [next] | [standalone]

#3946

Heinrich Wolf wrote:
> "janus" <emekamicro@gmail.com> schrieb im Newsbeitrag
> news:04ee4fd1-29ef-4640-a906-22055187c1e4@glegroupsg2000goo.googlegroups.com...
>> Hello All,
>>
>> I found this is a code I am currently studying, could someone
>> explain it to me.
>>
>> char * string = "Simulated Annealing = 12847369";
>> char * value = strchr(string, '=');
>
> strchr returns a char* pointing to the '=' within string:
>
>> *(value ++ ) = 0;
>
> I'm not quite sure about the preceedence of operations. But I think,
> first '=' is replaced by '\0', thus truncating string. value would
> then be "",
> but is advanced with ++ by on character in string, so pointing now to
> " 12847369"

That's how I read it too

>> printf("%s ==== %s", value, string);
>
> Using the explanation above I expect it to print
> "Simulated Annealing  ====  12847369"

It does print " 12847369  ====  Simulated Annealing  ",
after having fixed the 1st line...

Bye, Jojo 

[toc] | [prev] | [next] | [standalone]

#3948

"Joachim Schmitz" <jojo.nospam@schmitz-digital.de> schrieb im Newsbeitrag 
news:iqlm9g$rs0$1@usenet01.boi.hp.com...
...
> It does print " 12847369  ====  Simulated Annealing  ",
> after having fixed the 1st line...

Sure! I made a mistake. 

[toc] | [prev] | [next] | [standalone]

#3947

In article <iqlp5a$q4m$1@news.m-online.net>,
 "Heinrich Wolf" <invalid@invalid.invalid> wrote:

> "janus" <emekamicro@gmail.com> schrieb im Newsbeitrag 
> news:04ee4fd1-29ef-4640-a906-22055187c1e4@glegroupsg2000goo.googlegroups.com..
> .
> > Hello All,
> >
> > I found this is a code I am currently studying, could someone explain it 
> > to me.
> >
> > char * string = "Simulated Annealing = 12847369";
> > char * value = strchr(string, '=');
> 
> strchr returns a char* pointing to the '=' within string:
> 
> > *(value ++ ) = 0;
> 
> I'm not quite sure about the preceedence of operations. But I think,
> first '=' is replaced by '\0', thus truncating string. value would then be 
> "",
> but is advanced with ++ by on character in string, so pointing now to " 
> 12847369"
> 
> > printf("%s ==== %s", value, string);
> 
> Using the explanation above I expect it to print
> "Simulated Annealing  ====  12847369"

Actually the transpose
    1284736 === Simulated Annealing

-- 
Damn the living - It's a lovely life.           I'm whoever you want me to be.
Silver silverware - Where is the love?       At least I can stay in character.
Oval swimming pool - Where is the love?    Annoying Usenet one post at a time.
Damn the living - It's a lovely life.                              In 1492....

[toc] | [prev] | [next] | [standalone]

#3943

janus wrote:
> Hello All,
>
> I found this is a code I am currently studying, could someone explain
> it to me.
>
> char * string = "Simulated Annealing = 12847369";
> char * value = strchr(string, '=');
>
> *(value ++ ) = 0;

This should really result in a segfault, you're writing into a read only 
('const') string.

>
>
> printf("%s ==== %s", value, string);
>
> I noticed that sting will print in a new line, why this?

Guess this is undefined behavoir and bad luck. I had better luck: the 
program aborted.
Make the first line look like this and it should work properly:

char string[] = "Simulated Annealing = 12847369";

>
> char* karmarkar = "Karmarkar   958572";
> I want to use strchr to find the first occurrence of "space" in
> string karmarkar. How do I do that?

char * value = strchr(karmarkar, " ");

Bye, Jojo 

[toc] | [prev] | [next] | [standalone]

#3944

Joachim Schmitz wrote:
> janus wrote:
>> Hello All,
>>
>> I found this is a code I am currently studying, could someone explain
>> it to me.
>>
>> char * string = "Simulated Annealing = 12847369";
>> char * value = strchr(string, '=');
>>
>> *(value ++ ) = 0;
>
> This should really result in a segfault, you're writing into a read
> only ('const') string.
>
>>
>>
>> printf("%s ==== %s", value, string);
>>
>> I noticed that sting will print in a new line, why this?
>
> Guess this is undefined behavoir and bad luck. I had better luck: the
> program aborted.
> Make the first line look like this and it should work properly:
>
> char string[] = "Simulated Annealing = 12847369";
>
>>
>> char* karmarkar = "Karmarkar   958572";
>> I want to use strchr to find the first occurrence of "space" in
>> string karmarkar. How do I do that?
>
> char * value = strchr(karmarkar, " ");

Sorry, I meant
char * value = strchr(karmarkar, ' ');

 Bye, Jojo 

[toc] | [prev] | [next] | [standalone]

#3949

"Joachim Schmitz" <jojo.nospam@schmitz-digital.de> schrieb im Newsbeitrag 
news:iqlltc$rod$1@usenet01.boi.hp.com...
...
>> char * string = "Simulated Annealing = 12847369";
>> char * value = strchr(string, '=');
>>
>> *(value ++ ) = 0;
>
> This should really result in a segfault, you're writing into a read only 
> ('const') string.

You are right! I missed that.

...
>> char* karmarkar = "Karmarkar   958572";
>> I want to use strchr to find the first occurrence of "space" in
>> string karmarkar. How do I do that?
>
> char * value = strchr(karmarkar, " ");

char * value = strstr(karmarkar, " ");
or
char * value = strchr(karmarkar, ' ');

[toc] | [prev] | [next] | [standalone]

#4071

Heinrich Wolf wrote:
> "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> schrieb im
> Newsbeitrag news:iqlltc$rod$1@usenet01.boi.hp.com...
> ...
>>> char * string = "Simulated Annealing = 12847369";
>>> char * value = strchr(string, '=');
>>>
>>> *(value ++ ) = 0;
>>
>> This should really result in a segfault, you're writing into a read
>> only ('const') string.
>
> You are right! I missed that.
>
> ...
>>> char* karmarkar = "Karmarkar   958572";
>>> I want to use strchr to find the first occurrence of "space" in
>>> string karmarkar. How do I do that?
>>
>> char * value = strchr(karmarkar, " ");
>
> char * value = strstr(karmarkar, " ");
> or
> char * value = strchr(karmarkar, ' ');

Yes, of course, thanks for the correction.
My own correction to my post apparently didn't make it to the news server...

bye, Jojo 

[toc] | [prev] | [next] | [standalone]

#3951

On 05/14/2011 07:39 AM, Joachim Schmitz wrote:
> janus wrote:
...
>> char * string = "Simulated Annealing = 12847369";
>> char * value = strchr(string, '=');
>>
>> *(value ++ ) = 0;
> 
> This should really result in a segfault, you're writing into a read only 
> ('const') string.

It's not 'const'. Attempting to write to it does have explicitly
undefined behavior, (6.4.5p6). However, that's completely separate from
the fact that attempting to write to an object defined with 'const' is
undefined behavior (6.7.3p5).

The fact that the behavior is undefined doesn't mean that it "should
segfault". If the standard did say that it "should segfault", that would
correspond to defining the behavior. In point of fact, one of the single
most common ways programs behave, when their behavior is undefined, is
in precisely the way their author inappropriately expects them to behave.

-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#4070

James Kuyper wrote:
> On 05/14/2011 07:39 AM, Joachim Schmitz wrote:
>> janus wrote:
> ...
>>> char * string = "Simulated Annealing = 12847369";
>>> char * value = strchr(string, '=');
>>>
>>> *(value ++ ) = 0;
>>
>> This should really result in a segfault, you're writing into a read
>> only ('const') string.
>
> It's not 'const'.

Whatever, it is safe enough to assume them being const.

> Attempting to write to it does have explicitly
> undefined behavior, (6.4.5p6). However, that's completely separate
> from the fact that attempting to write to an object defined with
> 'const' is undefined behavior (6.7.3p5).
>
> The fact that the behavior is undefined doesn't mean that it "should
> segfault".

I didn't mean "should" as a requirement from the standard, more a personal 
wish.

> If the standard did say that it "should segfault", that
> would correspond to defining the behavior. In point of fact, one of
> the single most common ways programs behave, when their behavior is
> undefined, is in precisely the way their author inappropriately
> expects them to behave.

bye, Jojo 

[toc] | [prev] | [next] | [standalone]

#4077

"Joachim Schmitz" <jojo.nospam@schmitz-digital.de> writes:
> James Kuyper wrote:
>> On 05/14/2011 07:39 AM, Joachim Schmitz wrote:
>>> janus wrote:
>> ...
>>>> char * string = "Simulated Annealing = 12847369";
>>>> char * value = strchr(string, '=');
>>>>
>>>> *(value ++ ) = 0;
>>>
>>> This should really result in a segfault, you're writing into a read
>>> only ('const') string.
>>
>> It's not 'const'.
>
> Whatever, it is safe enough to assume them being const.

Unless that assumption leads you to expect warnings from the compiler if
you try to modify it.

The best approach is to add const qualifiers to the declarations:

const char *string = "Simulated Annealing = 12847369";
const char *value = strchr(string, '=');

But again, the compiler won't warn you if you omit the "const".

-- 
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"

[toc] | [prev] | [next] | [standalone]

#4124

Keith Thompson <kst-u@mib.org> writes:

> "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> writes:
>> James Kuyper wrote:
>>> On 05/14/2011 07:39 AM, Joachim Schmitz wrote:
>>>> janus wrote:
>>> ...
>>>>> char * string = "Simulated Annealing = 12847369";
>>>>> char * value = strchr(string, '=');
>>>>>
>>>>> *(value ++ ) = 0;
>>>>
>>>> This should really result in a segfault, you're writing into a read
>>>> only ('const') string.
>>>
>>> It's not 'const'.
>>
>> Whatever, it is safe enough to assume them being const.
>
> Unless that assumption leads you to expect warnings from the compiler if
> you try to modify it.
>
> The best approach is to add const qualifiers to the declarations:
>
> const char *string = "Simulated Annealing = 12847369";
> const char *value = strchr(string, '=');
>
> But again, the compiler won't warn you if you omit the "const".

In the non-standard but useful category...  you can get gcc to warn
about this by setting -Wwrite-strings.  It makes gcc non-conforming
although in such un-important and, as far as I know, safe corner cases
that I have it on all the time.

One such corner case is

  int f(const char (*p)[2]) { return **p; }

where a call such as f(&"*") requires a diagnostic in standard C
(despite being const safe).  By making string literals (well, the arrays
that they give rise to) have const elements, -Wwrite-strings suppresses
the required diagnostic.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#4148 — Rationale for

On 5/16/2011 5:00 PM, in thread "RE: I need help", Ben Bacarisse wrote:
> One such corner case is
>
>    int f(const char (*p)[2]) { return **p; }
>
> where a call such as f(&"*") requires a diagnostic in standard C
> (despite being const safe).  By making string literals (well, the arrays
> that they give rise to) have const elements, -Wwrite-strings suppresses
> the required diagnostic.
>

Speaking of which, does anyone have any clue as to the rationale behind 
why, in:

   int main(void) {
       char c = 'C';
       char * cp = &c;
       const char * ccp = &c;
       char ** cpp = &cp;
       #ifdef NOPE
       const char ** ccpp = &cp;
       #endif
       const char ** ccpp = &ccp;

       return 0;
     }

we are not permitted to (in a standard sense) "suddenly" 'const'-qualify 
the doubly-pointed-to type?  It would appear that 6.7.3p9 prevents us 
from having compatible types there, and I could understand not wanting 
to allow for the _removal_ of 'const' qualification, but couldn't it be 
helpful to add it?

Is it for symmetry?  Is it because the rules might be too complicated? :)

[toc] | [prev] | [next] | [standalone]

#4149 — Re: Rationale for Some of 6.7.3p9?

Oops.  I'm adding a [hopefully] more meaningful subject.

On 5/16/2011 11:40 PM, Shao Miller wrote:
> On 5/16/2011 5:00 PM, in thread "RE: I need help", Ben Bacarisse wrote:
>> One such corner case is
>>
>> int f(const char (*p)[2]) { return **p; }
>>
>> where a call such as f(&"*") requires a diagnostic in standard C
>> (despite being const safe). By making string literals (well, the arrays
>> that they give rise to) have const elements, -Wwrite-strings suppresses
>> the required diagnostic.
>>
>
> Speaking of which, does anyone have any clue as to the rationale behind
> why, in:
>
> int main(void) {
> char c = 'C';
> char * cp = &c;
> const char * ccp = &c;
> char ** cpp = &cp;
> #ifdef NOPE
> const char ** ccpp = &cp;
> #endif
> const char ** ccpp = &ccp;
>
> return 0;
> }
>
> we are not permitted to (in a standard sense) "suddenly" 'const'-qualify
> the doubly-pointed-to type? It would appear that 6.7.3p9 prevents us
> from having compatible types there, and I could understand not wanting
> to allow for the _removal_ of 'const' qualification, but couldn't it be
> helpful to add it?
>
> Is it for symmetry? Is it because the rules might be too complicated? :)

[toc] | [prev] | [next] | [standalone]

#4152 — Re: Rationale for Some of 6.7.3p9?

On 2011-05-17, Shao Miller <sha0.miller@gmail.com> wrote:
>> Speaking of which, does anyone have any clue as to the rationale behind
>> why, in:
>>
>> int main(void) {
>> char c = 'C';
>> char * cp = &c;
>> const char * ccp = &c;
>> char ** cpp = &cp;
>> #ifdef NOPE
>> const char ** ccpp = &cp;
>> #endif
>> const char ** ccpp = &ccp;
>>
>> return 0;
>> }
>>
>> we are not permitted to (in a standard sense) "suddenly" 'const'-qualify
>> the doubly-pointed-to type? It would appear that 6.7.3p9 prevents us
>> from having compatible types there, and I could understand not wanting
>> to allow for the _removal_ of 'const' qualification, but couldn't it be
>> helpful to add it?

If the conversion from "char **" to "const char **" were allowed without
a cast, the following would be legal:

const char c = 'A';
char *cp = NULL;
const char **ccpp = &cp; /* (1) */
*ccpp = &c;              /* (2) */
*cp = 'B';               /* (3) */

Here line (1) converts a char ** to const char ** and normally requires a
cast.  Line (2) is legal (ccpp is const char **, so *cpp is const char *,
and that can be set to point to a "const char" without problems.
Unfortunately that has set our char *cp to point to a const char without
casts, and line (3) then silently modifies a const object.

Converting char ** to const char * const* shouls be safe, though.
(Disclaimer: just a gut feeling.)

-- 
Heikki Kallasjoki
email: echo 'zfs+es_t_i@n_u.zf' | tr zen_muftis fuze_mints

[toc] | [prev] | [next] | [standalone]

#4154 — Re: Rationale for Some of 6.7.3p9?

On 2011-05-17, Heikki Kallasjoki <see@end.of.message.invalid> wrote:
> If the conversion from "char **" to "const char **" were allowed without
> a cast, the following would be legal:
[...]

Realized a little too late that this is actually a FAQ, with

http://c-faq.com/ansi/constmismatch.html

having a pretty much identical explanation. Oh well, reinventing the
wheel has a long historical tradition...

-- 
Heikki Kallasjoki
email: echo 'zfs+es_t_i@n_u.zf' | tr zen_muftis fuze_mints

[toc] | [prev] | [next] | [standalone]

#4160 — Re: Rationale for Some of 6.7.3p9?

On 2011-05-17, Heikki Kallasjoki <see@end.of.message.invalid> wrote:
> On 2011-05-17, Heikki Kallasjoki <see@end.of.message.invalid> wrote:
>> If the conversion from "char **" to "const char **" were allowed without
>> a cast, the following would be legal:
> [...]
>
> Realized a little too late that this is actually a FAQ, with
>
> http://c-faq.com/ansi/constmismatch.html
>
> having a pretty much identical explanation. Oh well, reinventing the
> wheel has a long historical tradition...

Reinventing the wheel is useful for educational purposes.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#4162 — Re: Rationale for Some of 6.7.3p9?

On 5/17/2011 02:13, Heikki Kallasjoki wrote:
> On 2011-05-17, Heikki Kallasjoki<see@end.of.message.invalid>  wrote:
>> If the conversion from "char **" to "const char **" were allowed without
>> a cast, the following would be legal:
> [...]
>
> Realized a little too late that this is actually a FAQ, with
>
> http://c-faq.com/ansi/constmismatch.html
>
> having a pretty much identical explanation. Oh well, reinventing the
> wheel has a long historical tradition...
>

Excellent explanation; thanks.  I guess that's why it's an FAQ... :)

Of course, there's still type punning and 'void *':

   int main(void) {
       const char c = 'x';
       char *p1;
       void *vp = &p1;
       const char **p2 = vp;
       *p2 = &c;
       *p1 = 'X';
       return 0;
     }

Have a pleasant day.

[toc] | [prev] | [next] | [standalone]

#4153 — Re: Rationale for

On 2011-05-17, Shao Miller <sha0.miller@gmail.com> wrote:
> Speaking of which, does anyone have any clue as to the rationale behind 
> why, in:
>
>    int main(void) {
>        char c = 'C';
>        char * cp = &c;
>        const char * ccp = &c;
>        char ** cpp = &cp;
>        #ifdef NOPE
>        const char ** ccpp = &cp;
>        #endif
>        const char ** ccpp = &ccp;
>
>        return 0;
>      }
>
> we are not permitted to (in a standard sense) "suddenly" 'const'-qualify 
> the doubly-pointed-to type?  It would appear that 6.7.3p9 prevents us 
> from having compatible types there, and I could understand not wanting 
> to allow for the _removal_ of 'const' qualification, but couldn't it be 
> helpful to add it?
>
> Is it for symmetry?  Is it because the rules might be too complicated? :)

Have you read http://c-faq.com/ansi/constmismatch.html ?

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web