Wanna discuss in the field of programming

>>testdirector
>If you insist, I have to ask you to compile and run (on any OS , any good compiler) it, it is guaranteed to work.

Who guaranteed that ? You ? or the almighty God ? For your satisfaction, I compiled and ran it in the following platforms :

1) x86 / Linux ( 2.6.8) / Gnu CC (3.3.5)
----> Resulted in "Segmentation Fault"

2) x86/ FreeBSD (5.4-STABLE) / Gnu CC ( 3.4.2)
----> Resulted in "Bus Error"

3) SPARC / Solaris ( 8 ) / Gnu CC ( 2.95.3)
----> Resulted in "Segmentation Fault"

I don't have other compilers but if you want, I will have it verified in any unhypothetical OS u prefer and with any _good_ compiler you name.

There are aspiring young programmers visiting this thread. Please verify what you say b4 posting it in this public forum.

Thanks Arch
This piece of code definitely works

char *p=(char *)malloc(6);
char *q="abcde";
char *r = p;

while(*p++=*q++);

GCC compiler, it crashes - one point to you.

Try MSDEV.EXE in XP. I did. it works just fine.

I'd like you to also try
const char *p = "abcde";

and other examples here in this thread.
I still let you analyze the result.

Which compiler you trust more? GCC or MSDEV.EXE?
And where has K&R said that "abcde" has to be protected? It is the GCC compiler which decided to put it in the read-only (.text??) section and you got the fault. There is an oversight on part of the GCC by doing just that. I let you find it.

The two statements
char *p = "abcde";
const char *p = "abcde";

should speak volume about the differences. The second one explicitly tells the compiler that content should be protected, I agree in this hands-down.

hey dudes
what about OpenGL programs, anybody know that.

This works also:

char* p;
char* q;

p = (char*)malloc(6);

q = "abrde";

while(*p++=*q++); //P gets incremented
char* x = &p[-6]; //I'd never used negative indexing in arrays but it works
cout << "\nNew p is: " << x << "\n"; //Will print abrde

I've to say I downloaded lcc32.exe and just compiled the code above and ran on my XP. Perfectly fine.

{
I do not want you guys to assume the following as part of my argument, nor me as almighty:-), but I've to say GCC is one of the most horrible source code I've seen for a compiler. Every thing in it is if and else statements, sharing global variables from one end to another; I felt I had to say grow up kid. One time I compiled a gcc for Linux using GCC. This I'm saying as a person who uses GCC for living from time to time (I use it to get compile warnings which Diab-CC or LINT does not give appropriately).
I've source code for another compiler I bought for $10; excellent state machines, small and neat! The compiler is called PCCOMPILER and is the first full blown compiler written by anybody based on K&R's semantics at the end of the book). I'll compile that compiler first in MSDEV and then compile our lovely code and let you know. I worry it might produce a binary for 16-bit MSDOS, in which case it will be an invalid test.
}


}
If I compile the code using gcc in XP for XP I feel it should crash.

>> Try MSDEV.EXE in XP. I did. it works just fine.
No need to. I trust you in that.
(I don't get surprised at anything that occurs on Windows)

>> Which compiler you trust more? GCC or MSDEV.EXE?
You give me 2 choices: an open source compiler which was used even to compile linux and disscussions about which still goes on among renowned programmers all around the world and a compiler written by a couple of programmers and is used by nobody around me and you ask me which one I trust. Please take a guess ( Ya! you are right .).

>> And where has K&R said that "abcde" has to be protected?
Did you read the book b4 you asking this question? If not , please do.
In K&R Sec. 5.5 p.104, they have explicitly mentioned that an attempt to change the characters of a string constant will give unexpected results. Now , an operation that may give unexpected results , should not be permitted at all and that was the reason GNU ppl discouraged it completely by making the operation fail every time rather that showing inconsistent behaviour.

Anyway, do u think K&R cud have written everything abt C in that small "white book" ?

>There is an oversight on part of the GCC by doing just that. I let you find it.
You are too quick to arrive at conclusions. Please go thru
ANSI Sec. 3.1.4, Sec. 3.5.7
ISO Sec. 6.1.4, Sec. 6.5.7
b4 blaming any party.

Now just blame the ppl who make the standards . One can always do that :-)


>char *p = "abcde";
>const char *p = "abcde";

>The second one explicitly tells the compiler that content should be protected.

Agree on that. .

>char *p = "abcde";
>const char *p = "abcde";
>The second one explicitly tells the compiler that content should be protected.

Wrong.

This is how it is.
Consider first one :
char *p = "abcde";
"abcde" is a string literal. It is a immutable and so should be placed in a memory that can not be modified.
char *p tells that p is a pointer to a character. The '=' says that currently p is pointing to the address where "abcde" string resides in the memory.
You can later change p to point to any char (whether const or non).

Now the second one:
const char *p = "abcde";
Same argument for "abcde"
const char *p tells p that p is a pointer to const char. You can only use p to point to const chars.

Compilers should always protect the string literals. "const char * " - does not tell compiler that the 'content' should be be protected. It only says that the pointer will point to non modifiable locations. The nature of string literal is such that they are placed in non modifiable locations.

You could, for example, write;
const char *p;
char * q = "abcde";
p = (const char *)q;

Do not ask me to define hackers.

Well I've to accept I'm terribly mistaken, assuming K&R is saying so - I probably have screwed up big time, despite the fact I've readily available compilers to support what I said.
I have not read K&R recently and do not have a copy of it right now, I'll get one from the library. I wonder what the ANSI and ISO are saying. But, beside having to blame the standards, I've the following point to make :

If "abcde" is a constant value to be stored in read-only areas, the compiler should stop there and give an error, saying a type mismatch. The case in point is,

const char p[] = "abcde";
char *q = p; /* Error. an attempt to assign different typed values */

The same way, if a compiler is smart enough to put "abcde" in rom in the following example,
char *p = "abcde";

the compiler should not compile it for the same reason.

Because the standard is against what I'm saying, I accept I was and am totally wrong.

Thank you for all the information you have given. I do not want to blame the standards. I do not want to say anything b4 I read (this is a big lesson for me), but I wonder what Bjarne Stroustroup has to say.

My apologies to testdirector.
The standard says modification of string literal is undefined. Remember that 'undefined' does not equal to 'not allowed'. GNU C does not allow it. Others might and IMHO those that do are stupid.

This is what I found:
The standard says [6.1.4], "If the program attempts to modify [a string literal], the behavior is undefined."
and
3.16 undefined behavior: Behavior, upon use of a nonportable or
erroneous program construct, or erroneous data, or of indeterminately
valued objects, for which this International Standard imposes no
requirements. Permissible undefined behavior ranges from ignoring
the situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic
of the environment (with or without the issuance of a diagnostic
method), to terminating a translation or execution (with the issuance
of a diagnostic message).
and
4 Compliance
A strictly conforming program shall ... not produce output
dependent on any unspecified, undefined, or implementation-defined
behavior, ...
... A conforming hosted implementation shall accept any strictly
conforming program.

digilat,
You are doing just fine, no need for apologies. Just the word undefined is a big blow to what I was bulshitting right from my a s s. I've been working without a C or C++ book for a while bootstrapping different processors and I knew it is gonna get me, it did today.
Cheers!

Javascript validation with pop up for RadioButtonList (not RadioButton) of .NET

I want to validate if any of radio button form RadioButtonList is checked.

Example:

var flag = 0;
if(document.Form1.RadioButtonList.SelectedIndex >= 0)
{
flag = true;
}

else
{
flage = false;
}

if(flag == false)
{
alert("One of the radio buttons is required to check");
return false;
}


Please your help.

>>testdirector, gidilat

I should admit that the use of "const" keyword is pretty confusing. There are 2 main contexts it is used in :
1) as in [[ const int i = 5; ]]
Well, in this case as expected the value of i cannot be modified later on.

2) as in [[ const char *p="abcde"; ]]
Now we had various opinions on that. Let's consider the following example :

const char *p="abcde"; // was explained by gidilat.
char q[] = "fghik"; // a character sequence enclosed within double quotes is not necessarily a string literal. Here, it is used to initialize an array and is modifiable later on.
q[4]='j'; // works fine
p=q; /*works fine. That's what is confusing me. Gidilat, in his discourse, mentioned that
"const char *p tells p that p is a pointer to const char. You can only use p to point to const chars." But, here p is pointing to a region which is modifiable and it works fine!! */
p[2]='a'; //as expected this will produce error (compile error).

So, IMO, const char *p just says that the memory region pointed to by p, shouldn't be modified. [ Neither does it tell the compiler explicitly to store the string pointed by p into a read-only region nor does it ensure that p can only point to const chars] (And if anybody tries to change a memory region using p, it can be detected at the compile time).

I've already a got a lesson trying to be a an Almighty, but still I've some juice to continue the discussion. Here is what I understand

1.
const char *p = "abcde"; // p points to a string whose content cannot be modified */
char p[] = "pqrst";

p = q; // the pointer can be modified, not the content
p[0] = 0; // error

2.
char *const p = "abcde";
char q[] = "pqrst";

p = q; /* compile error: p is a constant */

but
p[0] = 0; /* no compile error, but compiler dependant, may cause a fault */

3.
const char *const p = "abcde";
char q[] = "pqrst";

p = q; /* compile error: p is a constant */

p[0] = 0; /* compile error */

>> Neither does it tell the compiler explicitly to store the string pointed by p into a read-only region

Change of mind? Explain one more time because I think you are trying to say something else

>>test director
Yes. Change of mind. So what ?
My intution believed that you were correct about that but some dicussions from gidilat made my rethink it and had to change my mind. Anything bad about deleting misconceptions from one's mind ?

Nothing wrong! Very good, in fact!
I still think, to blame GCC:-), a compiler should not put the strings in ROM (unless the user has explicitly asked for protection using a key word such as const, in which case the compiler can make a decision what to do depending upon conditions). There is apparently two schools of thought for this statement out there in the IT world. In as simple a program as we have discussed, the user has seemingly done nothing wrong, no explicit warning or error, and it crashes for the reason that K&R, for some reason, had to allow the caveat and compilers are adhering to it. It's wrong, I think, for GCC to punish users for trying to use the string space. If the program crashes after the change of content at some point later on just because of the change, I understand it's up to the user to figure out, but as the fact of matter is, so be it. The user, of course, should avoid the modification of strings the way we've discussed.
Just a thought!

B4 discussing about and blaming GCC we shud first think why the heck the standard makers felt comfortable in letting a write operation on a string literal remain "undefined".
[ It surely is unintuitive, at least for the novices ].
Did they take the meaning of _literal_ too literally ? Did they see any possibility of some sort of optimization or gain in performance or ease in compiler design by letting it remain so ? Is it just historic reasons ?
Let me know, if you find the _real_ answer. :-)

The optimization is in space, I could think of (back then memory was scarce). You could merge two occurences of identical strings to be used. If two functions are sharing the string, one could change it without letting the other know about it (just like any other global variable). Let us face it, users must always be aware of global variables being shared.
But again, you could always put the string in writable memory to share and any side-effects are a bonus to the user to figure out as a reward for using identical string literals in more than one place. "Hello I'm a lesbian", could show up as "hello I'm a gay". It is very difficult, if not impossible, to keep track of then. The cure is take measures, or ask the compiler to not merge identical strings. Or put it in ROM, with our lovely result.

It could be historical, too.
The performance of compiling will not increase, rather probably would decrease because you have to compare a new string with all the previous strings every time a string literal is used, just to make sure whether you could optimize or not.

-----------
Any way, this simple program will probably not run in Linux if compiled with GCC (Is there MSDEV or VCC for Linux?). I do not have Linux right now, in a few days I'll. But it works fine in XP.

main()
{
"a'[0] = 'k';
}

Typo correction:
"a"[0] = 'k';