www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Okay, what happened to my literal strings?

reply "Burton Radons" <burton-radons shaw.ca> writes:
So I just installed DMD 2.004 (I thought I had a DMD 2.0 version already 
installed), and now, no matter which DMD 2.0 I install (removing the dmd and 
dm directories first), this code fails:

'char [] foo = "bar";'

With the error code:

'foo.d(1): Error: cannot implicitly convert expression ("bar") of type 
invariant char[3] to char[]'.

The only difference between the versions is that DMD 2.002 and up say 
"char[3u]" in the error message instead of "char[3]". All literal strings 
fail with this error message. The latest DMD 1.0 works fine, but I need 
traits. 
Sep 06 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Burton,

 So I just installed DMD 2.004 (I thought I had a DMD 2.0 version
 already installed), and now, no matter which DMD 2.0 I install
 (removing the dmd and dm directories first), this code fails:
 
 'char [] foo = "bar";'
 
 With the error code:
 
 'foo.d(1): Error: cannot implicitly convert expression ("bar") of type
 invariant char[3] to char[]'.
 
 The only difference between the versions is that DMD 2.002 and up say
 "char[3u]" in the error message instead of "char[3]". All literal
 strings fail with this error message. The latest DMD 1.0 works fine,
 but I need traits.
 

I can't seem to find the thread but This came up a few days ago in one of the NGs. I think the basic issue is that with the new const stuff an implicit case was removed. replace char[] with string and that error should go away.
Sep 06 2007
prev sibling next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Burton Radons wrote:
 So I just installed DMD 2.004 (I thought I had a DMD 2.0 version already 
 installed), and now, no matter which DMD 2.0 I install (removing the dmd 
 and dm directories first), this code fails:
 
 'char [] foo = "bar";'
 
 With the error code:
 
 'foo.d(1): Error: cannot implicitly convert expression ("bar") of type 
 invariant char[3] to char[]'.
 
 The only difference between the versions is that DMD 2.002 and up say 
 "char[3u]" in the error message instead of "char[3]". All literal 
 strings fail with this error message. The latest DMD 1.0 works fine, but 
 I need traits.

You missed the word "invariant". String literals are of type invariant(char)[n] in D 2.x. (Where 'n' is the length of the string.) This is part of the new const semantics in 2.x. You have two options: Either explicitly .dup the string literal, placing a mutable copy on the heap: char[] foo = "bar".dup; Or use the 'string' alias to use the immutable string literal directly: string foo = "bar"; 'string' is an alias to const(char)[]. You can implicitly convert invariant types to const types. Using 'string' is highly recommended. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Sep 06 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kirk McDonald wrote:
 Using 'string' is highly recommended.

I agree, for multiple reasons: 1) it is backward compatible with D 1.0 2) it is forward compatible in case we need to redesign const 3) it reads nicer Use char[] only if you specifically require a mutable string.
Sep 06 2007
parent Derek Parnell <derek psych.ward> writes:
On Thu, 06 Sep 2007 14:42:53 -0700, Walter Bright wrote:

 Kirk McDonald wrote:
 Using 'string' is highly recommended.

I agree, for multiple reasons: 1) it is backward compatible with D 1.0 2) it is forward compatible in case we need to redesign const 3) it reads nicer Use char[] only if you specifically require a mutable string.

FWIW, I'm using alias char[] text; a lot now. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Sep 06 2007
prev sibling parent reply "Burton Radons" <burton-radons shaw.ca> writes:
Ah, so 'const char [] foo = "bar";' works, does it? No thank you. Const 
forcing (whatever the name given) is the kind of tiddlywinks 
obsessive-compulsive bullshit that can't even be enforced so it's useless to 
everybody* which caused me to flee from C++. I've been using D as my primary 
language for... five years and four months now, and this lack has not 
resulted in a bug once. Needless to say, C++'s const didn't save me from a 
single bug either, but instead wasted my time (just like a bug does - the 
irony of many mollycoddling features is that they cause you to spend more 
time dealing with them than you would to deal with the bugs, if they even 
existed) by having me pour over code inserting const or casts everywhere 
like the virus it is.

This is _significantly_ against what I want from a language, and while I'm 
not sure how I'll feel in a day or two, my current inclination is to move on 
to another language or write my own. The many megabytes of code to retrofit 
don't help either.

* Some might be deluded into thinking it's useful to them for optimisation, 
bug prevention, or interface contracts. But the only thing circumventable 
const forcing does with any faculty is provide self-documentation, and even 
there the signal-to-noise ratio is pretty awful, it's easily abused (methods 
are frequently declared const in C++ when it's not a true requirement of 
what the method does, and it prevents situations where the method really is 
const but also modifies the object's data, which is not a paradox - the data 
might be cached or synthesized), often fraudulent, and usually not 
enforceable by the method. This is well-discussed and it seemed to be how 
Walter felt originally, so if someone can point out anything specific which 
changed his mind I'd be interested in seeing it. 
Sep 06 2007
next sibling parent Reiner Pope <some address.com> writes:
Burton Radons wrote:
 Ah, so 'const char [] foo = "bar";' works, does it? No thank you. Const 
 forcing (whatever the name given) is the kind of tiddlywinks 
 obsessive-compulsive bullshit that can't even be enforced so it's 
 useless to everybody* which caused me to flee from C++. I've been using 
 D as my primary language for... five years and four months now, and this 
 lack has not resulted in a bug once. Needless to say, C++'s const didn't 
 save me from a single bug either, but instead wasted my time (just like 
 a bug does - the irony of many mollycoddling features is that they cause 
 you to spend more time dealing with them than you would to deal with the 
 bugs, if they even existed) by having me pour over code inserting const 
 or casts everywhere like the virus it is.
 
 This is _significantly_ against what I want from a language, and while 
 I'm not sure how I'll feel in a day or two, my current inclination is to 
 move on to another language or write my own. The many megabytes of code 
 to retrofit don't help either.
 
 * Some might be deluded into thinking it's useful to them for 
 optimisation, bug prevention, or interface contracts. But the only thing 
 circumventable const forcing does with any faculty is provide 
 self-documentation, and even there the signal-to-noise ratio is pretty 
 awful, it's easily abused (methods are frequently declared const in C++ 
 when it's not a true requirement of what the method does, and it 
 prevents situations where the method really is const but also modifies 
 the object's data, which is not a paradox - the data might be cached or 
 synthesized), often fraudulent, and usually not enforceable by the 
 method. This is well-discussed and it seemed to be how Walter felt 
 originally, so if someone can point out anything specific which changed 
 his mind I'd be interested in seeing it.

You can always use "literal".dup if you don't want to use const. But you've never been *allowed* to modify string literals in D anyway, since they may be placed in ROM (eg on Linux). Making them invariant makes sense, then, as it expresses the already-present rule. -- Reiner
Sep 06 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Burton Radons Wrote:

 Ah, so 'const char [] foo = "bar";' works, does it? No thank you. Const 
 forcing (whatever the name given) is the kind of tiddlywinks 
 obsessive-compulsive bullshit that can't even be enforced so it's useless to 
 everybody* which caused me to flee from C++. I've been using D as my primary 
 language for... five years and four months now, and this lack has not 
 resulted in a bug once. Needless to say, C++'s const didn't save me from a 
 single bug either, but instead wasted my time (just like a bug does - the 
 irony of many mollycoddling features is that they cause you to spend more 
 time dealing with them than you would to deal with the bugs, if they even 
 existed) by having me pour over code inserting const or casts everywhere 
 like the virus it is.
 
 This is _significantly_ against what I want from a language, and while I'm 
 not sure how I'll feel in a day or two, my current inclination is to move on 
 to another language or write my own. The many megabytes of code to retrofit 
 don't help either.
 
 * Some might be deluded into thinking it's useful to them for optimisation, 
 bug prevention, or interface contracts. But the only thing circumventable 
 const forcing does with any faculty is provide self-documentation, and even 
 there the signal-to-noise ratio is pretty awful, it's easily abused (methods 
 are frequently declared const in C++ when it's not a true requirement of 
 what the method does, and it prevents situations where the method really is 
 const but also modifies the object's data, which is not a paradox - the data 
 might be cached or synthesized), often fraudulent, and usually not 
 enforceable by the method. This is well-discussed and it seemed to be how 
 Walter felt originally, so if someone can point out anything specific which 
 changed his mind I'd be interested in seeing it. 
 

As Reiner pointed out, modifying literal strings can lead to hard-to-find segfaults on Linux. It took me about an hour to find this the first time it happened to me when I started programming in C. I haven't made the mistake since, but still... For what its worth, I don't like const enforcing either, I think it's generally a waste of time. But it's very good, IMO, for one thing, and that thing is multi-threading. Knowing a value is invariant (and making sure the compiler knows it, too) means you don't have to lock it. For single-threaded programs, I would never write a "const". But locking/synchronization is slow, and if you're working on a big project (i.e. you're not familiar with thole codebase), it's always good to play it safe with shared class references. Knowing that the class reference is _invariant_ (not const as in C++ const, since there may be mutable references) means you don't need to lock it, increasing performance and making code easier to write. Walter said this about C++'s const, which displays many of the pathological problems you describe. D's const _is_ enforceable (well, const isn't, since it can be cast away, but invariant is, because invariant data can be placed into ROM).
Sep 06 2007
parent BCS <ao pathlink.com> writes:
Reply to Robert,

  D's const _is_ enforceable (well, const isn't, since it can be cast away

the only way to fully enforce const is to make refs a totally opaque type, disallow ASM etc. One of my first thoughts on seeing const in C++ was how easy it would be to get around it with sprintf/sscanf.
Sep 06 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Burton Radons wrote:
 Ah, so 'const char [] foo = "bar";' works, does it? No thank you. Const 
 forcing (whatever the name given) is the kind of tiddlywinks 
 obsessive-compulsive bullshit that can't even be enforced so it's 
 useless to everybody* which caused me to flee from C++.

I hear you, Burton, and I resisted const for a long time for exactly those reasons. But there are some compelling reasons to support const: 1) It opens the door to functional programming. This means that function calls can be automatically parallelized, which is going to become an increasingly big deal as people try to figure out how to use their multicore processors. Note that C++ const CANNOT do FP, and Java CANNOT do const. This will open up a huge advantage for D. 2) People who work on large projects with several teams modifying the code tell me unequivocably that they need some sort of const to enforce modularity. 3) Const improves the self-documentation of interfaces. As for strings being invariant, experience across many languages demonstrates that invariant strings are the most natural and productive way for people to think about them. I went through Phobos replacing the char[]'s with string's, and I found out a couple of things: 1) about 99% of the char[]'s were immutable anyway, and fit right in with being string's 2) the edits can be done mechanically, just s/char[]/string/ across the files, compile, and revert the very small number of ones that are mutable. For other data types, you can often just ignore const and not use it. I want to reiterate that C++ const fails at (1), (2), and (3), because C++ const is not transitive and is not enforced. Furthermore, the shortsighted "mutable" keyword just pulls the rug out from under generic programming with const.
Sep 06 2007
parent reply "Burton Radons" <burton-radons shaw.ca> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fbq3d5$1j0j$1 digitalmars.com...
 1) It opens the door to functional programming. This means that function 
 calls can be automatically parallelized, which is going to become an 
 increasingly big deal as people try to figure out how to use their 
 multicore processors.

 Note that C++ const CANNOT do FP, and Java CANNOT do const. This will open 
 up a huge advantage for D.

But you can't do any serious optimisations (like SIMD) unless if you have the function body, in which case proving it's procedural (or where the output is defined based on hermetic input) is relatively simple and completely foolproof. C-type languages have too much of a fetish for becoming undefined. If my function is declared const or invariant, but it's not (which the language rules allow), it's undefined and the worst kind of undefined - the kind which works initially, and might even work with -O. But then one day it doesn't because of new optimisations or because the file is compiled in a different environment or even because the operating system has been upgraded or the same code is executed on a different processor or the code is moved into a different context or it or a dependency has been slightly modified. This can cause major damage to older code and forces dozens of discrete optimisation flags to try to get it to compile properly with a little more speed. If the language could not be put into an undefined state (but could be put into an erroneous state which could be detected in debug compilations) then you'd be free to implement any compliant optimisation without worrying about how much code it breaks. "Aggressive optimisation" wouldn't be a bad thing in that context.
 2) People who work on large projects with several teams modifying the code 
 tell me unequivocably that they need some sort of const to enforce 
 modularity.

I don't think you believe it's adequate to do that. I'd expect that to be a good situation for programmers using const incorrectly, because they might need to cast const off code which they're not in control of, particularly when the internal rule is "you should const anything you don't modify" (which is an easy trap) instead of "you should const anything you /shouldn't/ modify".
 3) Const improves the self-documentation of interfaces.

In this context, const is being used to describe a contract with the user. But contracts of this sort are impossible to reduce to a combination of keywords and unenforcable in all contexts by the compiler; there are too many subtleties. This belongs in the documentation itself. A good example is "char* strchr (const char*, char)" from C. That implies that the return value is not a pointer to an index of the first argument, but it is, it's just not declared that way because the argument itself may not be const. So the signature misses the subtlety of the true contract. If the user uses this signature as self-documentation then they could easily make an error. If it were instead "const char* strchr (const char*, char)" then the contract goes beyond what is strictly required because it's so blunt, and interpreted as self-documentation requires the user to make a copy before any modifications of the return value (and makes it impossible to do certain operations). If we decide that we don't want to lie then we can declare it as "char* strchr (char*, char)", which implies that the function modifies the string (because of the absence of const), when it never does; interpreted as self-documentation you'd always call it with mutable data. There's no happy medium: in any case the self-documentation is wrong and harms the user. This could be "fixed" through a complex set of attributes, in this case something like "argument (a) strchr (const char*a, char)", so the compiler could assume that if it calls it with a non-const argument then it gets a non-const argument in return and vice versa, and the function can be implemented without casting off const. But even keeping these literate contracts to const there are many variations that would require the user to learn a new language to interpret them when simple human-interpreted language more than suffices. If the compiler has the function body, then it doesn't require the attribute in order to be able to detect an error and is free to be as subtle as it needs to be in order to inform the user of any true problems.
 As for strings being invariant, experience across many languages 
 demonstrates that invariant strings are the most natural and productive 
 way for people to think about them.

That's fine, I can and do work like that. I don't need to tell the compiler that I know I shouldn't be modifying the string.
 I went through Phobos replacing the char[]'s with string's, and I found 
 out a couple of things:
 1) about 99% of the char[]'s were immutable anyway, and fit right in with 
 being string's
 2) the edits can be done mechanically, just s/char[]/string/ across the 
 files, compile, and revert the very small number of ones that are mutable.

 For other data types, you can often just ignore const and not use it.

My experience with C++'s const, which looks just about identical in this factor, is that you can only ignore const for so long, and that it's better to const the hell out of your code in the first place to avoid the agony of trying to use a library which uses const when your code is const-free. D is even worse in this regard since all it has is a brute-force cast, rather than C++'s subtle const_cast and other variants. This strongly encourages you to let the library infect your code with const because if you cast something when dealing with the library, it could cause a bug if the library is updated and the type changes for a method you're casting.
 I want to reiterate that C++ const fails at (1), (2), and (3), because C++ 
 const is not transitive and is not enforced. Furthermore, the shortsighted 
 "mutable" keyword just pulls the rug out from under generic programming 
 with const. 

Sep 07 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Burton Radons wrote:
 
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fbq3d5$1j0j$1 digitalmars.com...
 1) It opens the door to functional programming. This means that 
 function calls can be automatically parallelized, which is going to 
 become an increasingly big deal as people try to figure out how to use 
 their multicore processors.

 Note that C++ const CANNOT do FP, and Java CANNOT do const. This will 
 open up a huge advantage for D.

But you can't do any serious optimisations (like SIMD) unless if you have the function body, in which case proving it's procedural (or where the output is defined based on hermetic input) is relatively simple and completely foolproof. C-type languages have too much of a fetish for becoming undefined. If my function is declared const or invariant, but it's not (which the language rules allow), it's undefined and the worst kind of undefined - the kind which works initially, and might even work with -O. But then one day it doesn't because of new optimisations or because the file is compiled in a different environment or even because the operating system has been upgraded or the same code is executed on a different processor or the code is moved into a different context or it or a dependency has been slightly modified. This can cause major damage to older code and forces dozens of discrete optimisation flags to try to get it to compile properly with a little more speed. If the language could not be put into an undefined state (but could be put into an erroneous state which could be detected in debug compilations) then you'd be free to implement any compliant optimisation without worrying about how much code it breaks. "Aggressive optimisation" wouldn't be a bad thing in that context.
 2) People who work on large projects with several teams modifying the 
 code tell me unequivocably that they need some sort of const to 
 enforce modularity.

I don't think you believe it's adequate to do that. I'd expect that to be a good situation for programmers using const incorrectly, because they might need to cast const off code which they're not in control of, particularly when the internal rule is "you should const anything you don't modify" (which is an easy trap) instead of "you should const anything you /shouldn't/ modify".
 3) Const improves the self-documentation of interfaces.

In this context, const is being used to describe a contract with the user. But contracts of this sort are impossible to reduce to a combination of keywords and unenforcable in all contexts by the compiler; there are too many subtleties. This belongs in the documentation itself. A good example is "char* strchr (const char*, char)" from C. That implies that the return value is not a pointer to an index of the first argument, but it is, it's just not declared that way because the argument itself may not be const. So the signature misses the subtlety of the true contract. If the user uses this signature as self-documentation then they could easily make an error. If it were instead "const char* strchr (const char*, char)" then the contract goes beyond what is strictly required because it's so blunt, and interpreted as self-documentation requires the user to make a copy before any modifications of the return value (and makes it impossible to do certain operations). If we decide that we don't want to lie then we can declare it as "char* strchr (char*, char)", which implies that the function modifies the string (because of the absence of const), when it never does; interpreted as self-documentation you'd always call it with mutable data. There's no happy medium: in any case the self-documentation is wrong and harms the user. This could be "fixed" through a complex set of attributes, in this case something like "argument (a) strchr (const char*a, char)", so the compiler could assume that if it calls it with a non-const argument then it gets a non-const argument in return and vice versa, and the function can be implemented without casting off const. But even keeping these literate contracts to const there are many variations that would require the user to learn a new language to interpret them when simple human-interpreted language more than suffices.

I think the actual "fix" in C++ would be just to define a version of strchr overloaded on const. So you have both: const char* strchr(const char*, char); and char* strchr(char*, char); If you pass it a char* that can be modified, it'll give you back one that can be modified. Otherwise it won't. --bb
Sep 07 2007
next sibling parent Regan Heath <regan netmail.co.nz> writes:
Bill Baxter wrote:
 Burton Radons wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fbq3d5$1j0j$1 digitalmars.com...
 1) It opens the door to functional programming. This means that 
 function calls can be automatically parallelized, which is going to 
 become an increasingly big deal as people try to figure out how to 
 use their multicore processors.

 Note that C++ const CANNOT do FP, and Java CANNOT do const. This will 
 open up a huge advantage for D.

But you can't do any serious optimisations (like SIMD) unless if you have the function body, in which case proving it's procedural (or where the output is defined based on hermetic input) is relatively simple and completely foolproof. C-type languages have too much of a fetish for becoming undefined. If my function is declared const or invariant, but it's not (which the language rules allow), it's undefined and the worst kind of undefined - the kind which works initially, and might even work with -O. But then one day it doesn't because of new optimisations or because the file is compiled in a different environment or even because the operating system has been upgraded or the same code is executed on a different processor or the code is moved into a different context or it or a dependency has been slightly modified. This can cause major damage to older code and forces dozens of discrete optimisation flags to try to get it to compile properly with a little more speed. If the language could not be put into an undefined state (but could be put into an erroneous state which could be detected in debug compilations) then you'd be free to implement any compliant optimisation without worrying about how much code it breaks. "Aggressive optimisation" wouldn't be a bad thing in that context.
 2) People who work on large projects with several teams modifying the 
 code tell me unequivocably that they need some sort of const to 
 enforce modularity.

I don't think you believe it's adequate to do that. I'd expect that to be a good situation for programmers using const incorrectly, because they might need to cast const off code which they're not in control of, particularly when the internal rule is "you should const anything you don't modify" (which is an easy trap) instead of "you should const anything you /shouldn't/ modify".
 3) Const improves the self-documentation of interfaces.

In this context, const is being used to describe a contract with the user. But contracts of this sort are impossible to reduce to a combination of keywords and unenforcable in all contexts by the compiler; there are too many subtleties. This belongs in the documentation itself. A good example is "char* strchr (const char*, char)" from C. That implies that the return value is not a pointer to an index of the first argument, but it is, it's just not declared that way because the argument itself may not be const. So the signature misses the subtlety of the true contract. If the user uses this signature as self-documentation then they could easily make an error. If it were instead "const char* strchr (const char*, char)" then the contract goes beyond what is strictly required because it's so blunt, and interpreted as self-documentation requires the user to make a copy before any modifications of the return value (and makes it impossible to do certain operations). If we decide that we don't want to lie then we can declare it as "char* strchr (char*, char)", which implies that the function modifies the string (because of the absence of const), when it never does; interpreted as self-documentation you'd always call it with mutable data. There's no happy medium: in any case the self-documentation is wrong and harms the user. This could be "fixed" through a complex set of attributes, in this case something like "argument (a) strchr (const char*a, char)", so the compiler could assume that if it calls it with a non-const argument then it gets a non-const argument in return and vice versa, and the function can be implemented without casting off const. But even keeping these literate contracts to const there are many variations that would require the user to learn a new language to interpret them when simple human-interpreted language more than suffices.

I think the actual "fix" in C++ would be just to define a version of strchr overloaded on const. So you have both: const char* strchr(const char*, char); and char* strchr(char*, char); If you pass it a char* that can be modified, it'll give you back one that can be modified. Otherwise it won't.

And in D we can use a template as the body of the function is the same for const or non-const data, eg. S[] strchr(S : S[], C)(S[], C); Two types S and C are required because sometimes you want to pass a char[] for the first and invariant(char) for the 2nd. Regan
Sep 10 2007
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote
 Burton Radons wrote:
 A good example is "char* strchr (const char*, char)" from C. That implies 
 that the return value is not a pointer to an index of the first argument, 
 but it is, it's just not declared that way because the argument itself 
 may not be const. So the signature misses the subtlety of the true 
 contract. If the user uses this signature as self-documentation then they 
 could easily make an error. If it were instead "const char* strchr (const 
 char*, char)" then the contract goes beyond what is strictly required 
 because it's so blunt, and interpreted as self-documentation requires the 
 user to make a copy before any modifications of the return value (and 
 makes it impossible to do certain operations). If we decide that we don't 
 want to lie then we can declare it as "char* strchr (char*, char)", which 
 implies that the function modifies the string (because of the absence of 
 const), when it never does; interpreted as self-documentation you'd 
 always call it with mutable data. There's no happy medium: in any case 
 the self-documentation is wrong and harms the user.

I think the actual "fix" in C++ would be just to define a version of strchr overloaded on const. So you have both: const char* strchr(const char*, char); and char* strchr(char*, char); If you pass it a char* that can be modified, it'll give you back one that can be modified. Otherwise it won't. --bb

This is not a "fix" as Burton is describing the constness as a contract for the compiler to interpret. It solves the problem of being able to pass const and non-const data to a function which does the same thing, and having it return the correct argument type. However, the compiler doesn't know that both functions are the same. How would the compiler know that the second function is not going to change any data in the string? Legally, the second function _can_ change data. The challenge is: Define the prototype for strchr in a way that it can be interpreted as not changing the data supplied by the argument, but will return the same type (const or non-const) that you pass in. Oh, and it can't cast away constness in the function, because that would be undefined ;) -Steve
Sep 10 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I realise this isn't actually meeting the challenge set, but there is one
really easy workaround you could do...

int strchr(const char *p, char c);

Just make the return value the offset from the start of p (or -1 if not
found) instead of a pointer. That way, on return from the function, p[n]
will be const or not const as desired.
Sep 10 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

OK, I figured it out. Here's how you do it in C.

 #define strchr(p,c) (p + istrchr(p,c))

 int istrchr(const char * p, char c)
 {
     int i;
     for (i=0; p[i]; ++i)
     {
         if (p[i] == c) return i;
     }
     return (const char *)0 - p;
 }


As required, the parameter is const at the callee site, but the output is
the same type as the input at the caller site.
Sep 10 2007