435,426 Members | 2,928 Online
Need help? Post your question and get tips & solutions from a community of 435,426 IT Pros & Developers. It's quick & easy.

# Some Questions

 P: n/a hello, i have some questions. 1) do constant expressions include string literals? for example, is "hello, world" a constant expression? 2) int i = 0; is the equal sign the assignment operator or is it only a symbol? (i think the last one is correct) 3) is an array a variable? for example: int i = 0; /* `i' is a variable*/ char *cPtr; /* `cPtr' is a variable */ int a[10]; /* is `a' a variable? */ K&R (2ed) says (paragraph 5.3; page 99): "[...] the value of a variable [...] of type array [...]". so i think an array is a variable. thanks Apr 11 '06 #1
27 Replies

 P: n/a In article <44***********************@reader2.news.tin.it>, fctk <-> wrote:1) do constant expressions include string literals? for example, is"hello, world" a constant expression? Not generally. It is, however, an address constant, which can be used in the context of initializers. 2) int i = 0; is the equal sign the assignment operator or is it only asymbol? (i think the last one is correct) That's a matter of semantics, but ask yourself whether the syntax would permit (say) int i -= 5; to determine whether the syntax permits assignment operators in general. 3) is an array a variable? for example: int i = 0; /* `i' is a variable*/ char *cPtr; /* `cPtr' is a variable */ int a[10]; /* is `a' a variable? */ The C89 standard does not have variables: it has objects, some of which are modifiable and some of which are not. Arrays are not modifiable, but array elements are modifiable. In your above examples, i, cPtr, and a are all "identifiers". -- Is there any thing whereof it may be said, See, this is new? It hath been already of old time, which was before us. -- Ecclesiastes Apr 11 '06 #2

 P: n/a Walter Roberson ha scritto: In article <44***********************@reader2.news.tin.it>, fctk <-> wrote:2) int i = 0; is the equal sign the assignment operator or is it only asymbol? (i think the last one is correct) That's a matter of semantics, but ask yourself whether the syntax would permit (say) int i -= 5; to determine whether the syntax permits assignment operators in general. the compiler does not permit: int i -= 5; so i guess the equal sign in a variable definition is not an operator, but a sign (such as the semicolon at the end of statements). 3) is an array a variable? for example: int i = 0; /* `i' is a variable*/ char *cPtr; /* `cPtr' is a variable */ int a[10]; /* is `a' a variable? */ The C89 standard does not have variables: it has objects, some of which are modifiable and some of which are not. Arrays are not modifiable, but array elements are modifiable. In your above examples, i, cPtr, and a are all "identifiers". but we can agree that a "variable" is a modifiable object, while a "constant" is a non-modifiable object. so an array is a constant, while array elements are variables. in my previous example, `i', `cPtr' and `a' are identifiers which refers to (in order) a variable, a variable, a constant. anyway if i compile the following little program: int main(void) { int a[10]; return 0; } i get the following warning: test.c: In function `main': test.c:2: warning: unused variable `a' please notice the word "variable"... i'm a bit confused. Apr 11 '06 #3

 P: n/a In article <44***********************@reader2.news.tin.it>, fctk <-> wrote:Walter Roberson ha scritto:anyway if i compile the following little program: int main(void) { int a[10]; return 0; } i get the following warning: test.c: In function `main': test.c:2: warning: unused variable `a' please notice the word "variable"... i'm a bit confused. C compilers are not required to emit a message in that case, so any message they do emit need not be semantically accurate. but we can agree that a "variable" is a modifiable object, while a "constant" is a non-modifiable object. int main(void) { const int i = 0; return 0; } \$ cc -fullwarn -o tc tc.c cc-1174 cc: WARNING File = tc.c, Line = 2 The variable "i" was declared but never referenced. const int i = 0; ^ \$ gcc -Wall -ansi -std=c89 -o tc tc.c tc.c: In function `main': tc.c:2: warning: unused variable `i' By your definition of variable, i is not a variable and hence the diagnostics would have to be incorrect [in the context of your definition.] This suggests to me that your definition of "variable" is not the same as is commonly used. But the C language doesn't care what your definition of "variable" is, as it does not talk about "variables". A question for you: is a malloc()'d block of memory a "variable" ? It is modifiable... -- "It is important to remember that when it comes to law, computers never make copies, only human beings make copies. Computers are given commands, not permission. Only people can be given permission." -- Brad Templeton Apr 11 '06 #4

 P: n/a > the compiler does not permit: int i -= 5; so i guess the equal sign in a variable definition is not an operator, but a sign (such as the semicolon at the end of statements). I wouldn't depend on that, as you can override this "assaignment operator" while you can't override a semicolon but we can agree that a "variable" is a modifiable object, while a "constant" is a non-modifiable object. so an array is a constant, while array elements are variables. Depends on what you mean by modifiable, do you mean that it's size can't be changed? if this is what you meant, then you'll have to distiguish between arrays allocated on the heap (which can be changed in size, under some limitations) and arrays allocated on the stack (which can't be changed in size) i get the following warning: test.c: In function `main': test.c:2: warning: unused variable `a' please notice the word "variable"... Well even if you declare a constant "variable" the compiler would warn that a "variable" is declared but not used... -- Abdo Haji-Ali Programmer In|Framez Apr 11 '06 #5

 P: n/a Walter Roberson ha scritto: This suggests to me that your definition of "variable" is not the same as is commonly used. But the C language doesn't care what your definition of "variable" is, as it does not talk about "variables". A question for you: is a malloc()'d block of memory a "variable" ? It is modifiable... according to my (wrong) definition, a malloc()'s block of memory is a variable. according to C language, i guess it is not even an object, because an object is "a location of memory which has a name", but malloc()'s blocks of memory have not a name. IMHO. Apr 11 '06 #6

 P: n/a Walter Roberson wrote: In article <44***********************@reader2.news.tin.it>, fctk <-> wrote: 1) do constant expressions include string literals? for example, is "hello, world" a constant expression? Not generally. It is, however, an address constant, which can be used in the context of initializers. 2) int i = 0; is the equal sign the assignment operator or is it only a symbol? (i think the last one is correct) That's a matter of semantics, but ask yourself whether the syntax would permit (say) int i -= 5; to determine whether the syntax permits assignment operators in general. The "=" in an initializer cannot be an assignment operator because the grammar does not permit assignment operators there. The production rule includes a literal "=". Although "=" also happens to match an assignment operator in another context, it's not the same token here. I wouldn't call that semantics; it's still pure syntax. When you say "semantics" you presumably refer to the fact that we often call the symbol "=" the "assignment operator", confusing levels. That this is easy to do doesn't make it a debatable issue, though. S. Apr 11 '06 #7

 P: n/a In article <44***********************@reader2.news.tin.it>, fctk <-> wrote:according to C language, i guess it is not even an object, because anobject is "a location of memory which has a name", but malloc()'s blocksof memory have not a name. C89 section 1.6: Object -- a region of data storage in the execution environment, the contents of which can represent values. Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined. When referenced, an object may be interrpreted as having a particular type; see 3.2.2.1. Notice no reference to having a name... -- "No one has the right to destroy another person's belief by demanding empirical evidence." -- Ann Landers Apr 11 '06 #8

 P: n/a In article <11*********************@g10g2000cwb.googlegroups. com>, Abdo Haji-Ali wrote: the compiler does not permit: int i -= 5; so i guess the equal sign in a variable definition is not an operator, but a sign (such as the semicolon at the end of statements). I wouldn't depend on that, as you can override this "assaignmentoperator"while you can't override a semicolon I don't think I know what you mean there by "override" that assignment operator ? Are you perchance thinking of C++'s ability to overload operators? but we can agree that a "variable" is a modifiable object, while a "constant" is a non-modifiable object. so an array is a constant, while array elements are variables. Depends on what you mean by modifiable, do you mean that it's sizecan't bechanged? if this is what you meant, then you'll have to distiguishbetweenarrays allocated on the heap (which can be changed in size, under somelimitations) and arrays allocated on the stack (which can't be changedinsize) Whyever would you want to distinguish on that basis? C has no idea what a "stack" or "heap" are. Objects in C are auto, static, or dynamically allocated, but as far as C is concerned, stack or heap or mmap or punch-tape is a petty implementation detail. i get the following warning: test.c: In function `main': test.c:2: warning: unused variable `a' please notice the word "variable"...Well even if you declare a constant "variable" the compiler would warnthata "variable" is declared but not used...--Abdo Haji-AliProgrammerIn|Framez -- "It is important to remember that when it comes to law, computers never make copies, only human beings make copies. Computers are given commands, not permission. Only people can be given permission." -- Brad Templeton Apr 11 '06 #9

 P: n/a fctk wrote: hello, i have some questions. 1) do constant expressions include string literals? for example, is "hello, world" a constant expression? 2) int i = 0; is the equal sign the assignment operator or is it only a symbol? (i think the last one is correct) 3) is an array a variable? for example: int i = 0; /* `i' is a variable*/ char *cPtr; /* `cPtr' is a variable */ int a[10]; /* is `a' a variable? */ K&R (2ed) says (paragraph 5.3; page 99): "[...] the value of a variable [...] of type array [...]". so i think an array is a variable. thanks fctk wrote: hello, i have some questions. 1) do constant expressions include string literals? for example, is "hello, world" a constant expression? 2) int i = 0; is the equal sign the assignment operator or is it only a symbol? (i think the last one is correct) 3) is an array a variable? for example: int i = 0; /* `i' is a variable*/ char *cPtr; /* `cPtr' is a variable */ int a[10]; /* is `a' a variable? */ K&R (2ed) says (paragraph 5.3; page 99): "[...] the value of a variable [...] of type array [...]". so i think an array is a variable. Here's what I think, sans not reading other's replies - ready for any flak/corrections, and ready to learn :-) 1. int n = 0; // 0 is a constant expression Likewise - char * p1 = "boo"; // "boo" is a constant expression used to set 'p'. Not sure if 'set' is right! char p2[] = "boo"; // "boo" is a constant expression used to set 'p'. Not sure if 'set' is right! p1, as it's a variable, may point somewhere else though. p2 cannot however - it's not a variable - it's a constant address see '3'. So, for your '1', 'YES' - "hello, world" is a constant expression. 2. int i = 0; The '=' here you may like to think of as assignment - although IMHO it's best to think of it as an 'initialization operator' - i is being initialized, not assigned to. int i; i = 0; // now '=' is an assignment operator. Don't know how much difference there is in C - but there's A LOT in C++ 3. An array name is a constant address - the address of the first element in the array - see '1' rayw Apr 11 '06 #10

 P: n/a fctk <-> writes: Walter Roberson ha scritto: This suggests to me that your definition of "variable" is not the same as is commonly used. But the C language doesn't care what your definition of "variable" is, as it does not talk about "variables". A question for you: is a malloc()'d block of memory a "variable" ? It is modifiable... according to my (wrong) definition, a malloc()'s block of memory is a variable. according to C language, i guess it is not even an object, because an object is "a location of memory which has a name", but malloc()'s blocks of memory have not a name. No, an object is a "region of data storage in the execution environment, the contents of which can represent values" (C99 standard, section 3.14). A block of memory allocated by malloc() is an object. Where did the definition as "a location of memory which has a name" come from? The C standard doesn't define or use use the term "variable", at least not formally, but it's a very common term in discussions about C (or about programming in general). It's not clear whether an unnamed object (such as the unnamed block allocated by malloc()) should be considered a "variable"; likewise for an object that's a component of a larger object. Personally, I use the term "variable" only informally, and only to refer to a declared named (and non-const) object. The question of whether other objects qualify as "variables" is not a particularly interesting one; if I avoid using the word in such cases, I don't have to decide one way or the other, and I avoid arguments with people who will inevitably think I'm misusing the word. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 11 '06 #11

 P: n/a ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: In article <44***********************@reader2.news.tin.it>, fctk <-> wrote: [...]2) int i = 0; is the equal sign the assignment operator or is it only asymbol? (i think the last one is correct) That's a matter of semantics, but ask yourself whether the syntax would permit (say) int i -= 5; to determine whether the syntax permits assignment operators in general. It's a matter of syntax, not semantics. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 11 '06 #12

 P: n/a In article , Keith Thompson wrote:ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: In article <44***********************@reader2.news.tin.it>, fctk <-> wrote:[...]2) int i = 0; is the equal sign the assignment operator or is it only asymbol? (i think the last one is correct) That's a matter of semantics, but It's a matter of syntax, not semantics. OED indicates: Semantic: B. n. pl. 1.a = SEMASIOLOGY. Als, (the study or analysis of) the relationships between linguistic symbols and their meanings. Const. as sing. and pl. Now the usual word in this sense. The equal sign is a "linguistic symbol". The -meaning- of that linguistic symbol in context is semantics, not syntax. Syntax tells you that the equal sign must occur there, but not what it denotes. -- "law -- it's a commodity" -- Andrew Ryan (The Globe and Mail, 2005/11/26) Apr 11 '06 #13

 P: n/a I don't think I know what you mean there by "override" that assignment operator ? Are you perchance thinking of C++'s ability to overload operators? Yep! Sorry I keep forgetting that this is a C newsgroup not a C++ one... Whyever would you want to distinguish on that basis? C has no idea what a "stack" or "heap" are. Objects in C are auto, static, or dynamically allocated, but as far as C is concerned, stack or heap or mmap or punch-tape is a petty implementation detail. Again, sorry. However, same thing applies for dynamically allocated arrays vs. static arrays... Abdo Haji-Ali Programmer In|Framez Apr 11 '06 #14

 P: n/a In article <11*********************@v46g2000cwv.googlegroups. com>, Abdo Haji-Ali wrote: [I wrote] Whyever would you want to distinguish on that basis? C has no idea what a "stack" or "heap" are. Objects in C are auto, static, or dynamically allocated, but as far as C is concerned, stack or heap or mmap or punch-tape is a petty implementation detail. Again, sorry. However, same thing applies for dynamically allocatedarrays vs. static arrays... C does not have dynamically allocated arrays. C has dynamically allocated objects, the bytes of which may be interpreted as if an array (or structure or simple non-composite value.) If one has a dynamically allocated object in C which has been interpreted as an array, the array cannot be resized: the object can be resized and the resulting object interpreted as a different array with the same values as before [up to the minimum of the old and new sizes.] To make the difference slightly clearer: one could allocate [sufficient] dynamic memory and use it as if an array of 10 int values. One could then realloc() the object and interpret that as a structure the first component of which is an array of 10 int values, but then followed by (say) a union, then a composite structure, then another array... If the semantics of realloc() applied to "a dynamically allocated array" was that it "resized the array" then you would not be able to do that: those semantics would require that the expanded space only be used for additional array elements of the same type. When you malloc() or calloc() and convert the resulting void* into a different pointer type, you impose a form on the dynamic memory. When you realloc(), you toss away knowledge of that form and you get back a blob of memory -- which you can then impose a different form on, and you can access the previously-stored values provided that the new form is "compatable" with the old in the accessed locations. Sure, the new form might happen to be a larger version of the array you had before, but the semantics don't require that at all. -- Prototypes are supertypes of their clones. -- maplesoft Apr 11 '06 #15

 P: n/a Walter Roberson wrote: In article <44***********************@reader2.news.tin.it>, fctk <-> wrote: 2) int i = 0; is the equal sign the assignment operatoror is it only a symbol? (i think the last one is correct) That's a matter of semantics, but ask yourself whether the syntax would permit (say) int i -= 5; to determine whether the syntax permits assignment operators in general. I think it helps to consider that int i = 0; is shorthand for int i = {0}; and that {0} is not an expression. Those are declarations, not statements. And those are initializations, not assignments. -- pete Apr 11 '06 #16

 P: n/a On Tue, 11 Apr 2006 19:18:07 +0200, in comp.lang.c , fctk <-> wrote: but we can agree that a "variable" is a modifiable object, This isn't a variable according to my understanding - any non-constant is a variable, eg const int x; The only actual constants in C are defined at compile time. while a"constant" is a non-modifiable object. so an array is a constant, whilearray elements are variables. No. Mark McIntyre -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan Apr 11 '06 #17

 P: n/a Walter Roberson wrote: In article , Keith Thompson wrote: ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: In article <44***********************@reader2.news.tin.it>, fctk <-> wrote: [...] 2) int i = 0; is the equal sign the assignment operator or is it only a symbol? (i think the last one is correct) That's a matter of semantics, but It's a matter of syntax, not semantics. OED indicates: Semantic: B. n. pl. 1.a = SEMASIOLOGY. Als, (the study or analysis of) the relationships between linguistic symbols and their meanings. Const. as sing. and pl. Now the usual word in this sense. The equal sign is a "linguistic symbol". I follow you so far. The -meaning- of that linguistic symbol in context is semantics, not syntax. Syntax tells you that the equal sign must occur there, but not what it denotes. Yes, but the standard defines the *syntactical* category "assignment-operator", and the elements of that category cannot occur in an initializer. What "=" denotes in an initializer is irrelevant (although it arguably does not denote *anything*): whatever it is, it's not an assignment operator. To argue otherwise is to argue that the grammar does not define what (syntactically) an assignment operator is, which is a questionable position to say the least. The question was not "what does '=' mean in an initializer" but "is '=' an assignment operator in an initializer", and the answer to the latter question is no, because *syntactically* assignment operators cannot occur in initializers (at the top level; they can of course occur in the initializing expression). "What is assignment" is a question of semantics. "Is '=' an assignment operator here" is a question of syntax. Alternative views on the distinction between these are possible, but they are unlikely to have the same broad applicability or offer more understanding. This is orthogonal to general philosophical discussions about where, if anywhere, the line between syntax and semantics can or should be drawn, which is far more off-topic than what the current discussion is already edging towards. S. Apr 11 '06 #18

 P: n/a rayw wrote: char p2[] = "boo"; // "boo" is a constant expression used to set 'p'. Not sure if 'set' is right! "boo" is shorthand for {'b', 'o', 'o', '\0'} p1, as it's a variable, may point somewhere else though. p2 cannot however it's not a variable it's a constant address see '3'. p2 is an lvalue expression of type array of four char. sizeof p2 equals 4. 3. An array name is a constant address - the address of the first element in the array - see '1' Only when the array has static duration, does it's conversion to a pointer yield an address constant. -- pete Apr 11 '06 #19

 P: n/a Keith Thompson ha scritto: No, an object is a "region of data storage in the execution environment, the contents of which can represent values" (C99 standard, section 3.14). A block of memory allocated by malloc() is an object. Where did the definition as "a location of memory which has a name" come from? K&R (2ed) - A5 (p197): "An object is a named region of storage". Apr 12 '06 #20

 P: n/a pete ha scritto: I think it helps to consider that int i = 0; is shorthand for int i = {0}; and that {0} is not an expression. Those are declarations, not statements. And those are initializations, not assignments. so in: int i = ((564 * 793) / 5 ); ((564 * 793) / 5 ) is not an expression? Apr 12 '06 #21

 P: n/a fctk <-> writes: pete ha scritto: I think it helps to consider that int i = 0; is shorthand for int i = {0}; and that {0} is not an expression. That's a consistent way of looking at it, but it's not how I'd put it. I'd say that {0} is longhand for 0, not that 0 is shorthand for {0}. Those are declarations, not statements. And those are initializations, not assignments. so in: int i = ((564 * 793) / 5 ); ((564 * 793) / 5 ) is not an expression? Yes, it is. In a declaration such as int i = blah; blah is an "initializer". An initializer can be, among other things, an assignment-expression (i.e., an expression other than a comma-expression) or an initalizer-list enclosed in '{' and '}' characters. So given int i = ((564 * 793) / 5 ); ((564 * 793) / 5 ) is an expression. Given int i = { ((564 * 793) / 5 ) }; ((564 * 793) / 5 ), but { ((564 * 793) / 5 ) } is not. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 12 '06 #22

 P: n/a fctk <-> writes: Keith Thompson ha scritto: No, an object is a "region of data storage in the execution environment, the contents of which can represent values" (C99 standard, section 3.14). A block of memory allocated by malloc() is an object. Where did the definition as "a location of memory which has a name" come from? K&R (2ed) - A5 (p197): "An object is a named region of storage". I just got around to checking this, and you're right. I believe that's an error in K&R2 (not currently listed at ). I've just sent an e-mail message to Dennis Ritchie about this. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Apr 14 '06 #24

 P: n/a "Chris Torek" wrote in message news:e1********@news4.newsguy.com... In article <44***********************@reader2.news.tin.it>, fctk <-> wrote: We can see that it is a matter of mag when we look at Historical C -- the stuff that came before even K&R C -- where initializers were written without the "=" sign: This dialect of C also had the assignment operators spelled the other way around; instead of "debug++" we might write: debug =+ 1; The syntax was changed because it was inconsistent (or even "ugly"), and expressions like "k=-5" were ambiguous to human readers, who might see that as either "k = -5" (set k to -5) or "k =- 5" (decrement k by 5). Do you have more information on that? I thought I read somewhere that the "reversed" operators of early C were changed because bison and lex grammars had parsing/lexing problems. Rod Pemberton Apr 14 '06 #25

 P: n/a Rod Pemberton wrote: "Chris Torek" wrote in message news:e1********@news4.newsguy.com...> In article <44***********************@reader2.news.tin.it>, fctk <-> wrote: We can see that it is a matter of mag when we look at Historical C -- the stuff that came before even K&R C -- where initializers were written without the "=" sign: This dialect of C also had the assignment operators spelled the other way around; instead of "debug++" we might write: debug =+ 1; The syntax was changed because it was inconsistent (or even "ugly"), and expressions like "k=-5" were ambiguous to human readers, who might see that as either "k = -5" (set k to -5) or "k =- 5" (decrement k by 5). Do you have more information on that? I thought I read somewhere that the "reversed" operators of early C were changed because bison and lex grammars had parsing/lexing problems. Rod Pemberton In K&R 1 on page 212, A.17 Anachronisms: explains it like Chris does. There is no mention of bison or lex. -- Joe Wright "Everything should be made as simple as possible, but not simpler." --- Albert Einstein --- Apr 14 '06 #26

 P: n/a Joe Wright writes: Rod Pemberton wrote: "Chris Torek" wrote in message news:e1********@news4.newsguy.com...>> In article <44***********************@reader2.news.tin.it>, fctk <-> wrote: We can see that it is a matter of mag when we look at Historical C -- the stuff that came before even K&R C -- where initializers were written without the "=" sign: This dialect of C also had the assignment operators spelled the other way around; instead of "debug++" we might write: debug =+ 1; The syntax was changed because it was inconsistent (or even "ugly"), and expressions like "k=-5" were ambiguous to human readers, who might see that as either "k = -5" (set k to -5) or "k =- 5" (decrement k by 5). Do you have more information on that? I thought I read somewhere that the "reversed" operators of early C were changed because bison and lex grammars had parsing/lexing problems. Rod Pemberton In K&R 1 on page 212, A.17 Anachronisms: explains it like Chris does. There is no mention of bison or lex. Also, I don't see why it should be a particular problem for bison or lex, particularly since lex tends to match the longest possible sequence, IIRC. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ Apr 14 '06 #27