473,325 Members | 2,774 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

How to eliminate this global variable, silent?

When I control if I print messages, I usually use a global variable
"int silent". When I set "-silent" flag in my command line
parameters, I set silent = 1 in my main.c.
I have many functions that may print some messages.

foo(...)
{
if (!silent)
printf("Msg1\n");
}
foo2(...)
{
if (!silent)
printf("Msg2\n");
}
and so on...
Is the above bad coding practice? How to eliminate the variable
"silent" but achieve the same effect?
Jun 27 '08
112 5310
ym******@gmail.com wrote:
On Apr 16, 5:29 pm, Joe Wright <joewwri...@comcast.netwrote:
>Richard Tobin wrote:
>>In article <gNSdnRYJHJ7QipvVnZ2dnUVZ_gqdn...@comcast.com>,
Joe Wright <joewwri...@comcast.netwrote:
The single paragraph says an identifier is a name used to refer to any
of several things including objects. "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." At least Brian
Kernighan thinks object and variable are interchangeable.
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."
Yes, that's what he said.
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.
This is where we see things differently. Your example "int a[10];" says
a is an array 10 of int. Its storage class is either automatic or static
depending on where it is declared, file scope or block scope. It is an
object regardless of its storage class. The members of the array have
the same storage class as the array itself. a[2] is an object of type
int and is variable.
malloc(10); // variable leak!
I've never seen the above line.
>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?
It is a variable I'd say of type unsigned char. Consider..
*(unsigned char *)&x[2] = 42;
>There is nothing
disqualifying about x[2] as a name.

"x[2]" is a name?
Sure. name == identifier. Isn't x[2] an identifier?
Yevgen
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jun 27 '08 #101
Joe Wright wrote:
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.)

--
"Oh, but it can be applied to almost any situation." /Tactics of Mistake/

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

Jun 27 '08 #102
Chris Dollin <ch**********@hp.comwrites:
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.
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>

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 27 '08 #103
user923005 <dc*****@connx.comwrote:
>
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
Jun 27 '08 #104
Richard Heathfield <rj*@see.sig.invalidwrote:
la************@siemens.com said:
>ym******@gmail.com wrote:
>>>
As far as I know, the C standard does not define "variable".

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.

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
Jun 27 '08 #105
la************@siemens.com said:

<snip>
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
You PICK these. Don't try to deny it again. You PICK them. I swear you do.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #106
Keith Thompson wrote:
Chris Dollin <ch**********@hp.comwrites:
>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?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jun 27 '08 #107
Joe Wright wrote:
Keith Thompson wrote:
Chris Dollin <ch**********@hp.comwrites:
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_ ]
Jun 27 '08 #108
ja*********@verizon.net wrote:
Joe Wright wrote:
>Keith Thompson wrote:
>>Chris Dollin <ch**********@hp.comwrites:
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_ ]
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?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jun 27 '08 #109
Joe Wright <jo********@comcast.netwrites:
[...]
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.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 27 '08 #110
Richard Heathfield wrote:
la************@siemens.com said:
>>
Pitiful. Just pitiful. -- Calvin

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

Jun 27 '08 #111
Joe Wright wrote:
ja*********@verizon.net 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.
Jun 27 '08 #112
Chris Dollin <ch**********@hp.comwrote:
>
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
Jun 27 '08 #113

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.