By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,426 Members | 2,928 Online
Bytes IT Community
+ Ask a Question
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
Share this Question
Share on Google+
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 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.

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 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 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 an
object is "a location of memory which has a name", but malloc()'s blocks
of 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 <ah***@inframez.com> 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 "assaignment
operator"
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 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)
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 warn
that
a "variable" is declared but not used...

--
Abdo Haji-Ali
Programmer
In|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 <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
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 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.


It's a matter of syntax, not semantics.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 11 '06 #12

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> 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". 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 <ah***@inframez.com> 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 allocated
arrays 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 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.


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, while
array 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 <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> 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 <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 12 '06 #22

P: n/a
>>> 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)
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
That's a matter of semantics, but
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
It's a matter of syntax, not semantics.

In article <e1**********@canopus.cc.umanitoba.ca>
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote: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.


This discussion is especially confusing (or potentially quite
confusing) because there are two English words, "syntax" and
"semantics", and two C-Standard-ese words, "syntax" and "semantics",
with somewhat different definitions.

The only way to talk about all this without getting confused is
to re-label all four words. Since color is not available and
case is confusing, I think the best way is to make up entirely
new words:

mag: "C syntax", i.e., the grammar in the C standard;
pag: "C semantics", i.e., the stuff that goes in paragraphs
under a section labeled "semantics";
vag: "English syntax" (we mostly are not using this one here);
zag: "English semantics", as per the definition quoted above.

The "=" in an initializer such as "int i = 0" is definitely,
certainly, nothing but mag and not pag. It is, however, a
matter of zag (and not vag), as Walter Roberson points out,
when we start talking about whether it is "only" a symbol
(but, as he also noted, it is definitely not an assignment
operator as defined by mag and described under pag), since
"assignment operators" (as per mag) include things like +=
and -=.

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:

int debug 0;
int interactive 1;

main(argc, argv)
char **argv;
{
int i 1;
char *s;
int read_stdin 0;

while (i < argc) {
s = argv[i];
/* -d = debug */
/* -q = quiet = not-interactive */
/* - = read stdin */
if (*s == '-') {
if (s[1] == 'd')
debug++;
else if (s[1] == 'q')
interactive = 0;
else if (s[1] == '\0')
read_stdin = 1;
else
usage();
}
...
i++;
}
...
}

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).

(This version of C also had oddities like:

printf(2, "some debug message\n");

where the first argument, if not a string, was treated as a Unix
file descriptor. The two were distinguished purely by "magic":
strings were known to have addresses greater than 19. This trick
stopped working when the system was ported to split-I&D PDP-11s,
and the data segment began at 0 just like the code segment.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Apr 13 '06 #23

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
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>).

I've just sent an e-mail message to Dennis Ritchie about this.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 14 '06 #24

P: n/a

"Chris Torek" <no****@torek.net> wrote in message
news:e1********@news4.newsguy.com...
In article <44***********************@reader2.news.tin.it>, fctk <->
wrote:
<snip> 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:

<code snip> 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" <no****@torek.net> wrote in message
news:e1********@news4.newsguy.com...
> In article <44***********************@reader2.news.tin.it>, fctk <->

wrote:
<snip>
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:


<code snip>
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 <jo********@comcast.net> writes:
Rod Pemberton wrote:
"Chris Torek" <no****@torek.net> wrote in message
news:e1********@news4.newsguy.com...
>> In article <44***********************@reader2.news.tin.it>, fctk <->

wrote:
<snip>
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:

<code snip>
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

P: n/a

"Micah Cowan" <mi***@cowan.name> wrote in message
news:87************@mcowan.barracudanetworks.com.. .
Joe Wright <jo********@comcast.net> writes:
Rod Pemberton wrote:
"Chris Torek" <no****@torek.net> wrote in message
news:e1********@news4.newsguy.com...
>>>> In article <44***********************@reader2.news.tin.it>, fctk <-> wrote:
<snip>
> 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:
>
<code snip>
> 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.


Well, I can't find it at the moment. I did find these:

Wikipedia
http://en.wikipedia.org/wiki/C_programming_language
"The =+ operator was changed to += to remove the semantic ambiguity created
by the construct i=+10, which could be interpreted as either i =+ 10 or i =
+10. "
"The Development of the C Language" by Dennis M. Ritchie, Bell Labs/Lucent
Technologies, Murray Hill, NJ 07974 USA

On page 5,
"More History
After the TMG version of B was working, Thompson rewrote B in itself (a
bootstrapping
step). During development, he continually struggled against memory
limitations: each language
addition inflated the compiler so it could barely fit, but each rewrite
taking advantage of the feature
reduced its size. For example, B introduced generalized assignment
operators, using x=+y
to add y to x. The notation came from Algol 68 [Wijngaarden 75] via McIlroy,
who had incorporated
it into his version of TMG. (In B and early C, the operator was spelled =+
instead of += ;
this mistake, repaired in 1976, was induced by a seductively easy way of
handling the first form
in B's lexical analyzer.)"
From 7.14.1 of 1975's "C Reference Manual", Dennis M. Ritchie, Bell
Telephone Laboratories, Murray Hill, New Jersey 07974, I know the following
operators were reverse from what they are today:

7.14.2 lvalue =+ expression
7.14.3 lvalue =- expression
7.14.4 lvalue =* expression
7.14.5 lvalue =/ expression
7.14.6 lvalue =% expression
7.14.7 lvalue =>> expression
7.14.8 lvalue =<< expression
7.14.9 lvalue =& expression
7.14.10 lvalue =^ expression
7.14.11 lvalue = | expression
Oh well, it's not important.
Rod Pemberton
Apr 14 '06 #28

This discussion thread is closed

Replies have been disabled for this discussion.