How to eliminate this global variable, silent?

[user923005]

It makes a normative reference to ISO/IEC 2382-1:1993, Information
Technology -- Vocabulary -- Part 1: Fundamental terms, which one would
expect to contain a definition.  If anyone has access to that document,
it would be interesting to find out what it has to say.

From this draft:
http://old.jtc1sc36.org/doc/36N0646.pdf

We have this:
3.5.2.3
variable
computational object to which a value of a particular datatype is
associated at any given time; and to which different values of the
same datatype may be associated at different times

 

[Richard]

The canonical statement is:

int *x = malloc(10 * sizeof *x);

Assuming success, I would say this allocates an array 10 of int.

Yes. Clearly.

I wouldn't think of, say, the third int in the array as a variable.

Of course x[2] (the third int) is a variable.

It's an integer. Would you not say x is the variable? .....

But I might well call x[2] a variable. If f() returned x I would be
slightly less inclined to call f(x)[2] a variable. All quite
illogical in a sense, but that's the way it is. I call objects
variables when I think of them as named. And the more complicated the
expression, the less name-like it is.

I didn't realize we were discussing your preferences rather than
accepted definitions of the term 'variable'.

I just checked with a very exerienced colleague, and he thinks
that "x" is a variable but "x[2]" isn't. So between him and K&R,
I think my position is a sensible, moderate one

You have a 'very experienced colleague' who disagrees with Brian
Kernighan? And you side with him? Who pray tell is this genius?

Brian Kernighan would be the first to admit he is not always right
either.

Of course x is a variable. It is a pointer to int. x[0] through x[9]
are also discrete objects and variables of type int. There is nothing
disqualifying about x[2] as a name.

Are you sure they are not simply allocations in which to store
variables?

You know, just to play the word games prevailent in c.l.c....

 

[James Kuyper]

The version I gave yesterday, which said something like "visible given
a suitable declaration" seems to cover it. I take "suitable declaration"
to imply "and not an (unsuitable) shadowing one", but you can spell
that out if you like.

I don't think it's a good idea to define the term in terms of possible
modified versions of the code; it should be definable in terms of the
code as actually written.

Furthermore, shadowing isn't a language-independent concept; for that
matter, neither is declaration.

I also don't like the fact that the presence of a shadowing declaration
renders a variable non-global. With my definition, it remains global, it
just can't be used within the shadow.

 

[Richard Tobin]

The version I gave yesterday, which said something like "visible given
a suitable declaration" seems to cover it. I take "suitable declaration"
to imply "and not an (unsuitable) shadowing one", but you can spell
that out if you like.

[...]

I also don't like the fact that the presence of a shadowing declaration
renders a variable non-global.[/QUOTE]

My definition doesn't do that. It says it is global if it is visible
everywhere where {there's a suitable declaration and it isn't shadowed}.

-- Richard

 

[Richard Tobin]

You have a 'very experienced colleague' who disagrees with Brian
Kernighan? And you side with him? Who pray tell is this genius?

[/QUOTE]

Brian Kernighan would be the first to admit he is not always right
either.

It's not an issue of right and wrong. My intention was to show the
range of ways the term is used, and to suggest that Kernighan's was at
one end of that range.

-- Richard

 

[ymuntyan]

Human language has subtleties that are not always amenable to
precise definitions.

When you do

int *x = malloc(10 * sizeof(x));

you would probably agree that you are allocating an array of 10
objects. But would you say that you are allocating an array of
10 variables?

The canonical statement is:

int *x = malloc(10 * sizeof *x);

Assuming success, I would say this allocates an array 10 of int.

I wouldn't think of, say, the third int in the array as a variable.

Of course x[2] (the third int) is a variable.

But I might well call x[2] a variable. If f() returned x I would be
slightly less inclined to call f(x)[2] a variable. All quite
illogical in a sense, but that's the way it is. I call objects
variables when I think of them as named. And the more complicated the
expression, the less name-like it is.

I didn't realize we were discussing your preferences rather than
accepted definitions of the term 'variable'.

I just checked with a very exerienced colleague, and he thinks
that "x" is a variable but "x[2]" isn't. So between him and K&R,
I think my position is a sensible, moderate one

You have a 'very experienced colleague' who disagrees with Brian
Kernighan? And you side with him? Who pray tell is this genius?

In fact you are misinterpreting the words of Kernighan:
"An object, sometimes called a variable, is a location in
storage and its interpretation depends on two main attributes:
its storage class and its type."
For storage class you need a declaration, and that's variables:
in "int a[10];" the variable "a" has storage class, not the
object '*(char*)(a[2])'. And if you think this quoted text
says that the block of memory allocated by malloc() is a
variable, you simply have (too) strong imagination.

malloc(10); // variable leak!

Of course x is a variable. It is a pointer to int. x[0] through x[9] are
also discrete objects and variables of type int.

So, the first byte of x[2] is what (note, the *byte*, not
a char object or something, just that single byte region
of storage)? It's an object by definition. Is it a variable?
Of what type?

There is nothing
disqualifying about x[2] as a name.

"x[2]" is a name?

Yevgen

 

[Chris Dollin]

Sure. name == identifier. Isn't x[2] an identifier?

As far as I can tell, not as the term is normally used, no.
(And I wouldn't call `x[2]` a name, either.)

I'd call `x[2]` an expression. If I wanted to suggest that it
had an address/was assignable to, I'd probably call it an lvalue
expression.

"Identifier" would for me be more-or-less the same as "name",
and I'd mean lexical items that could be bound to values.
(I might also accept identifiers proceeded by scope operations,
like the Java `ClassName.memberName` or the C++ `ClassName::memberName`,
as identifiers, but C doesn't have those.)

 

[Keith Thompson]

Sure. name == identifier. Isn't x[2] an identifier?

That was a joke, right? No, x[2] certainly isn't an identifier.

As far as I can tell, not as the term is normally used, no.
(And I wouldn't call `x[2]` a name, either.)

I'd call `x[2]` an expression. If I wanted to suggest that it
had an address/was assignable to, I'd probably call it an lvalue
expression.

"Identifier" would for me be more-or-less the same as "name",
and I'd mean lexical items that could be bound to values.
(I might also accept identifiers proceeded by scope operations,
like the Java `ClassName.memberName` or the C++ `ClassName::memberName`,
as identifiers, but C doesn't have those.)

I think you meant "as names" rather than "as identifiers".

As it happens, the C standard doesn't define the term "name", but it
does define "external name" and "internal name" (C99 6.4.2.1p5); both
are restricted to identifiers. I might think of "struct_obj.member"
as a name, but as the C standard uses the term is isn't one.

<OT>Other languages have a more expansive definition of "name" that
includes things like x[2] and foo.bar, but C doesn't.</OT>

 

[lawrence.jones]

From this draft:
http://old.jtc1sc36.org/doc/36N0646.pdf

We have this:
3.5.2.3
variable
computational object to which a value of a particular datatype is
associated at any given time; and to which different values of the
same datatype may be associated at different times

But that definition is from ISO/IEC 11404, not ISO/IEC 2382.

-Larry Jones

It's not denial. I'm just very selective about the reality I accept.
-- Calvin

 

[lawrence.jones]

(e-mail address removed) said:


You mean you don't?!? You're on the Committee, right? And, according to my
C89 Draft, you (or someone with a remarkably similar name) was on the
Committee right back in C89 days.

'Twas me. What's worse, I wasn't just a member, but was the editor for
the C99 standard. But no, I don't have a copy. Like most ISO
documents, it's ridiculously expensive and there's no concept of
"courtesy copies" for other committees.

My observation is this: how is it possible for a Standard to make a major
normative reference to a fundamental document without at least those
committee members who are able to vote on the inclusion or otherwise of
that reference having good access to, and a reasonable working knowledge
of, that document?

In the early days, there was an officially designated Vocabulary
Representative on the committee whose job it was to consult such
documents and report back to the committee as needed, but the basic
terminology used in the standard has been stable enough for a long
enough time that the position has been allowed to go vacant. We
basically just have faith that the underlying definitions remain
sufficiently stable as well.

What's really scary, though, is that when ANSI C became ISO C, the
normative reference was changed from the ANSI dictionary to the ISO
dictionary without anyone (so far as I know) comparing the corresponding
definitions, we just had faith that they were "close enough".

-Larry Jones

Pitiful. Just pitiful. -- Calvin

 

[jameskuyper]

Joe Wright wrote:

Sure. name == identifier. Isn't x[2] an identifier?

That was a joke, right? No, x[2] certainly isn't an identifier.

Keith, I have snipped your response to Chris Dollin. I fear we're
getting off (my) topic. I'm using K&R2 as reference. A4. "Identifiers or
names refer to a variety of things (amonng them) objects." "An object,
sometimes called a variable, is a location in storage..".

A prior message in this thread suggests given 'int a[10];' a is an
object and a variable and a[2] is neither. a is an object, an array 10
of int but is a variable? No says I, the modifiable lvalue thing. But
a[2] is an object of type int and is variable.

If a[2] refers to a location in storage of an object or variable, why
isn't it an identifier?

Because "referring to the location in storage of an object or
variable" is a matter of semantics, and identifiers are defined in
terms of syntax, not semantics. Nor is there any particularly close
connection between the syntax of identifiers and the semantics you
describe. Some identifiers do identify an object, but many identify
other things: for instance macros, functions, structure tags,
enumeration constants, or statement labels. Furthermore, not
everything that does refer to an object is an identifier; some of the
things that do so are expressions, as is true in this case.

Section 6.4.2.1p1 specifies, with great precision, what an identifier
is:

_identifier_:
_identifier-nondigit_
_identifier identifier-nondigit_
_identifier digit_

_identifier-nondigit_:
_nondigit_
_universal-character-name_
other implementation-defined characters

_nondigit_: one of
_ a b c d e f g h i j k l m
n o p q r s t u v w x y z
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z

_digit_: one of
0 1 2 3 4 5 6 7 8 9

Paragraph 3 explains the "other implementation-defined characters":
"An implementation may allow multibyte characters that are not part of
the basic source character set to
appear in identifiers; which characters and their correspondence to
universal character names is implementation-defined."

The characters '[' and ']' do not meet the requirements for qualifying
as either "digits" or "non-digits". Since they are part of the basic
source character set, they also can't qualify under the 'other'
category. Therefore they cannot appear anywhere in an identifier.

The C standard describes a[2] as a postfix-expression consisting of
the identifier "a", which parses as a postfix-expression in it's own
right, the subscript operator consisting of the tokens "[" and "]",
and the integer literal "2" which parses as an expression in this
context. See 6.5.2p1:

_postfix-expression_:
....
_postfix-expression_ [ _expression_ ]

 

[Keith Thompson]

Damn, this is a tough room. I now concede a[2] an expression, not an
identifier.

Perhaps what you meant is that a[2] is a name, rather than an
identifier. (But given the way the C standard uses the term "name",
it's not a name either.)

But it is an object of type int and a variable. Right?

It's an object of type int, yes. More precisely, a[2] is an
expression, more specifically an lvalue, that refers to an object of
type int. We can and do refer to that object as a[2]. Of course
there are plenty of other ways we could refer to it, such as *(a+2) or
*p (the latter requires an appropriate declaration and current value
for p).

Is it a variable? That depends on how you define the term. If you
can construct a definition of the term "variable" based on terms
defined in the C standard, you can determine whether a[2] is a
variable. Somebody else can just as easily construct another
definition that settles the question the other way.

 

[Chris Dollin]

(e-mail address removed) said:

You PICK these. Don't try to deny it again. You PICK them. I swear you do.

It's remarkable how a bunch of randomly-selected quotes will offer
up something surprisingly apposite. It's probably reporting bias;
all the unapposite ones fall into the organic bit-bucket ...

--
"Some of these", Hazleton had said, looking at a /A Clash of Cymbals/
just-completed tangle of wires, lenses, antennae and
kernels of metal with rueful respect, "ought to prove pretty potent in the
pinch. I just wish I knew which ones they were."

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

 

[James Kuyper]

(e-mail address removed) wrote: ....

Section 6.4.2.1p1 specifies, with great precision, what an identifier
is:

_identifier_:
_identifier-nondigit_
_identifier identifier-nondigit_
_identifier digit_

_identifier-nondigit_:
_nondigit_
_universal-character-name_
other implementation-defined characters

_nondigit_: one of
_ a b c d e f g h i j k l m
n o p q r s t u v w x y z
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z

_digit_: one of
0 1 2 3 4 5 6 7 8 9

Paragraph 3 explains the "other implementation-defined characters":
"An implementation may allow multibyte characters that are not part of
the basic source character set to
appear in identifiers; which characters and their correspondence to
universal character names is implementation-defined."

The characters '[' and ']' do not meet the requirements for qualifying
as either "digits" or "non-digits". Since they are part of the basic
source character set, they also can't qualify under the 'other'
category. Therefore they cannot appear anywhere in an identifier.

The C standard describes a[2] as a postfix-expression consisting of
the identifier "a", which parses as a postfix-expression in it's own
right, the subscript operator consisting of the tokens "[" and "]",
and the integer literal "2" which parses as an expression in this
context. See 6.5.2p1:

_postfix-expression_:
...
_postfix-expression_ [ _expression_ ]

Damn, this is a tough room. I now concede a[2] an expression, not an
identifier. But it is an object of type int and a variable. Right?

I agree that it is an object; it is a sub-object of the aggregate object
referred to by 'a'. However, my understanding is that a variable is a
named object, i.e. one that can be identified using just an identifier.
Therefore, I don't agree that it is a variable.

However, I see that user92300 has recently cited ISO/IEC 11404
(unfortunately, not the relevant standard) which defines the term
"variable", in a way that's incompatible with my understanding. I'm
preparing myself for the possibility that the relevant standard (ISO/IEC
2382) has a similar definition. If so, then you're right on both counts.

 

[lawrence.jones]

It's remarkable how a bunch of randomly-selected quotes will offer
up something surprisingly apposite. It's probably reporting bias;
all the unapposite ones fall into the organic bit-bucket ...

But for some reason, Calvin & Hobbes quotes seem to do it much more
often than other quotes. It either says something about the
universality of Calvin & Hobbes, or something else.

I suspect there's a potential PhD thesis lurking here somewhere.

-Larry Jones

Something COULD happen today. And if anything DOES,
by golly, I'm going to be ready for it! -- Calvin