using macros ...

[hasadh]

Hello,

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and
got compilation errors. He advised me to use them as enums instead of
macros. is he right ???

(in my code the macros are used as return values from fns mostly)

awaiting your replies.

regards,
prakas

[Joona I Palaste]

hasadh <h_****@hotmail.com> scribbled the following:

Hello, probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and
got compilation errors. He advised me to use them as enums instead of
macros. is he right ??? (in my code the macros are used as return values from fns mostly) awaiting your replies.

If this is some kind of debate, I'm willing to take your side on this.
Your friend is correct that he can't use OK, TRUE, FALSE or FAILURE as
variable or function names, but why should he? It's a common spelling
convention that variable and function names are in lower case and macro
names are in upper case.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller

[Joona I Palaste]

no****@nospam.invalid <no****@nospam.invalid> scribbled the following:

Hello Joona I Palaste, On 13-Oct-2003, Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

It's a common spelling

Oh! really?

convention that variable and function names are in lower case and macro
names are in upper case.

I have no clue as to what you are meaning with your question.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You could take his life and..."
- Mirja Tolsa

[E. Robert Tisdale]

hasadh wrote:

In my software, I used macros like OK, TRUE, FALSE, FAILURE.
A friend who included this code as a library into his module
said that, in his code, he couldn't use the above words
as function names or variable names and got compilation errors.
He advised me to use them as enums instead of macros.
Is he right?

The problem is name space pollution.
Your definitions of global names conflict with other definitions.
This problem is easily solved by prepending a unique prefix
to all of the global names in your module:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

[E. Robert Tisdale]

Joona I Palaste wrote:

It's a common spelling convention that
variable and function names are in lower case
and macro names are in upper case.

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

[Jeffrey D. Smith]

"Ravi" <ra**@despammed.com> wrote in message
news:ln********************************@4ax.com...

On 13-Oct-2003, h_****@hotmail.com (hasadh) wrote:

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and

BTW you define macros like this
#define TRUE 1
etc.
and after that you would not use them as function name :)

OTOH
#define printf PRN
and then you may use PRN as a function name.

got compilation errors.

Which compiler? What did you do, some more details :)

He advised me to use them as enums instead of
macros. is he right ???

Was he trying to say this would solve the problem with
compilation?

Yes it will. Changing to enums will avoid the
preprocessor substitution. The compiler can
see the enum symbols and distinguish them from
other uses (like function calls).

[Eric Sosman]

"E. Robert Tisdale" wrote:

hasadh wrote:

In my software, I used macros like OK, TRUE, FALSE, FAILURE.
A friend who included this code as a library into his module
said that, in his code, he couldn't use the above words
as function names or variable names and got compilation errors.
He advised me to use them as enums instead of macros.
Is he right?

The problem is name space pollution.
Your definitions of global names conflict with other definitions.
This problem is easily solved by prepending a unique prefix
to all of the global names in your module:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

Why in the world should the programmer's use of the
identifiers reserved for the programmer be called "name
space pollution?" Or to put it another way: What is
there about the identifier `moduleName_OK' that makes it
one whit less "polluting" than `OK'?

C preprocessor macros are dangerous -- in the wrong
hands, as are all C constructs. The error in the example
above suggests that ERT's hands may not be the right ones,
and may go some ways toward explaining why he finds macros
dangerous. Programmers who deploy a little more skill and
a little more care will find macros both safe and helpful.

--
Er*********@sun.com

[CBFalconer]

"E. Robert Tisdale" wrote:

Joona I Palaste wrote:

It's a common spelling convention that
variable and function names are in lower case
and macro names are in upper case.

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

Don't spout nonsense and corrupt the children. Those have quite
distinct uses, and cannot substitute for macros.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

"E. Robert Tisdale" wrote:

hasadh wrote:

In my software, I used macros like OK, TRUE, FALSE, FAILURE.
A friend who included this code as a library into his module
said that, in his code, he couldn't use the above words
as function names or variable names and got compilation errors.
He advised me to use them as enums instead of macros.
Is he right?

The problem is name space pollution.
Your definitions of global names conflict with other definitions.
This problem is easily solved by prepending a unique prefix
to all of the global names in your module:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

This is bad advice, and indicative of failure to limit access to
the narrowest possible scope and failure to understand the
language.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Jeremy Yallop]

E. Robert Tisdale wrote:

Joona I Palaste wrote:

It's a common spelling convention that
variable and function names are in lower case
and macro names are in upper case.

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

Not at all. There are lots of things that are possible to achieve
with macros, but impossible with const and inline functions. In fact,
although inline functions can occasionally be used in place of macros,
const cannot generally be used to replace #define-d symbolic
constants, since the value of a const variable cannot be used in a
constant expression.

This has been explained to you before, but you continue to spread the
same misinformation. Please stop.

http://groups.google.com/groups?selm...B3%40yahoo.com
http://groups.google.com/groups?selm...gnus%40usa.net

Jeremy.

[Jeremy Yallop]

E. Robert Tisdale wrote:

Joona I Palaste wrote:

It's a common spelling convention that
variable and function names are in lower case
and macro names are in upper case.

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

Not at all. There are lots of things that are possible to achieve
with macros, but impossible with const and inline functions. In fact,
although inline functions can occasionally be used in place of macros,
const cannot generally be used to replace #define-d symbolic
constants, since the value of a const variable cannot be used in a
constant expression.

This has been explained to you before, yet you continue to spread the
same misinformation. Please stop.

http://groups.google.com/groups?selm...B3%40yahoo.com
http://groups.google.com/groups?selm...gnus%40usa.net

Jeremy.

[Richard Bos]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

hasadh wrote:

In my software, I used macros like OK, TRUE, FALSE, FAILURE.
A friend who included this code as a library into his module
said that, in his code, he couldn't use the above words
as function names or variable names and got compilation errors.
He advised me to use them as enums instead of macros.
Is he right?
The problem is name space pollution.

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

So, erm... please explain how, exactly,

enum predefined_values {no, yes};

is any less namespace-polluting than

#define NO 0
#define YES 1

Richard

[Alex]

"Jeffrey D. Smith" <xa***@email.com> wrote in message
news:LU*****************@newsread3.news.pas.earthl ink.net...

The compiler can see the enum symbols and distinguish them from other
uses (like function calls).

No it can't, although a name clash with an enum constant will probably give
a less confusing error message, eg:

#define foo 42
int foo(void) {
return 42;
}

test.c:2: parse error before numeric constant

enum {foo = 42};
int foo(void) {
return 42;
}

test.c:2: `foo' redeclared as different kind of symbol
test.c:1: previous declaration of `foo'

Alex

[pete]

hasadh wrote:

Hello,

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and
got compilation errors. He advised me to use them as enums instead of
macros. is he right ???

(in my code the macros are used as return values from fns mostly)

awaiting your replies.

About the only use I've ever had for enums,
is as return values from functions.
I think they're OK for that purpose.

--
pete

[hasadh]

Hi,

you say that "The compiler can see the enum symbols and distinguish them from
other uses (like function calls)." .
but i get compilation error if i use a enum symbol and a same fn name. eg
enum {TRUE 1}

and
void TRUE() - gives compilation error in vc++ .

"Jeffrey D. Smith" <xa***@email.com> wrote in message news:<LU*****************@newsread3.news.pas.earth link.net>...

"Ravi" <ra**@despammed.com> wrote in message
news:ln********************************@4ax.com...

On 13-Oct-2003, h_****@hotmail.com (hasadh) wrote:

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and

BTW you define macros like this
#define TRUE 1
etc.
and after that you would not use them as function name :)

OTOH
#define printf PRN
and then you may use PRN as a function name.

got compilation errors.

Which compiler? What did you do, some more details :)

He advised me to use them as enums instead of
macros. is he right ???

Was he trying to say this would solve the problem with
compilation?

Yes it will. Changing to enums will avoid the
preprocessor substitution. The compiler can
see the enum symbols and distinguish them from
other uses (like function calls).

[Joona I Palaste]

hasadh <h_****@hotmail.com> scribbled the following:

Hi, you say that "The compiler can see the enum symbols and distinguish them from
other uses (like function calls)." .
but i get compilation error if i use a enum symbol and a same fn name. eg
enum {TRUE 1} and
void TRUE() - gives compilation error in vc++ .

True, true... (pun not intended), but like I said in my previous reply,
why would anyone *want* to name their function "TRUE"?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr

[Mark McIntyre]

On 14 Oct 2003 12:48:30 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:

hasadh <h_****@hotmail.com> scribbled the following:

Hi,

you say that "The compiler can see the enum symbols and distinguish them from
other uses (like function calls)." .
but i get compilation error if i use a enum symbol and a same fn name. eg
enum {TRUE 1}

and
void TRUE() - gives compilation error in vc++ .

True, true... (pun not intended), but like I said in my previous reply,
why would anyone *want* to name their function "TRUE"?

Well, DS9K's compiler has a language extension function
int TRUE(void)
{
return cmos.status.power_is_switched_on;
}
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Eric Sosman]

Richard Bos wrote:

So, erm... please explain how, exactly,

enum predefined_values {no, yes};

is any less namespace-polluting than

#define NO 0
#define YES 1

Slight thread drift, but true horror story: I once
tracked down a bug in code written by someone who believed
firmly that enum's were superior to macros as a way to
introduce manifest integer constants. He had all sorts of
high-falutin' theoretical grounds for his preference, but
the bug he'd committed cast doubt on just how much weight
his opinions deserved:

typedef enum { TRUE, FALSE } Boolean;

--
Er*********@sun.com

[Dan Pop]

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Slight thread drift, but true horror story: I once
tracked down a bug in code written by someone who believed
firmly that enum's were superior to macros as a way to
introduce manifest integer constants. He had all sorts of
high-falutin' theoretical grounds for his preference, but
the bug he'd committed cast doubt on just how much weight
his opinions deserved:

typedef enum { TRUE, FALSE } Boolean;

An excellent device for code obfuscation purposes!

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joona I Palaste]

Dan Pop <Da*****@cern.ch> scribbled the following:

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Slight thread drift, but true horror story: I once
tracked down a bug in code written by someone who believed
firmly that enum's were superior to macros as a way to
introduce manifest integer constants. He had all sorts of
high-falutin' theoretical grounds for his preference, but
the bug he'd committed cast doubt on just how much weight
his opinions deserved:

typedef enum { TRUE, FALSE } Boolean;

An excellent device for code obfuscation purposes!

Other such devices include:
typedef struct { /* ... */ } ínt;
but that would not be portable across systems with different charsets.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Shh! The maestro is decomposing!"
- Gary Larson

[Dan Pop]

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Dan Pop <Da*****@cern.ch> scribbled the following:

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Slight thread drift, but true horror story: I once
tracked down a bug in code written by someone who believed
firmly that enum's were superior to macros as a way to
introduce manifest integer constants. He had all sorts of
high-falutin' theoretical grounds for his preference, but
the bug he'd committed cast doubt on just how much weight
his opinions deserved:

typedef enum { TRUE, FALSE } Boolean;

An excellent device for code obfuscation purposes!

Other such devices include:
typedef struct { /* ... */ } ínt;
but that would not be portable across systems with different charsets.

Much simpler and perfectly portable:

#define int double

*after* including all the headers. Use "signed" when you really mean
"int". Yup, the standard allows it!

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[E. Robert Tisdale]

Richard Bos wrote:

So, erm... please explain how, exactly,

enum predefined_values {no, yes};

is any less namespace-polluting than

#define NO 0
#define YES 1 cat main.c #include<stdio.h>
#define NO 0
#define YES 1

int main(int argc, char* argv[]) {
int YES = 1;
return 0;
}
gcc -Wall -std=c99 -pedantic -O2 -o main main.c main.c: In function `main':
main.c:7: parse error before numeric constant
cat main.c #include<stdio.h>
typedef enum answer { NO, YES } answer;

int main(int argc, char* argv[]) {
int YES = 1;
return 0;
}
gcc -Wall -std=c99 -pedantic -O2 -o main main.c

main.c: In function `main':
main.c:7: warning: unused variable `YES'

[Ben Pfaff]

Da*****@cern.ch (Dan Pop) writes:

Much simpler and perfectly portable:

#define int double

*after* including all the headers. Use "signed" when you really mean
"int". Yup, the standard allows it!

Really? Then the following should also be allowed, but GCC
chokes on it:

#include <stddef.h>

#define void

int main(void) {
int *p = NULL;
return 0;
}
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

[Christopher Benson-Manica]

Eric Sosman <Er*********@sun.com> spoke thus:

"E. Robert Tisdale" wrote:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous -- in the wrong
hands, as are all C constructs. The error in the example
above suggests that ERT's hands may not be the right ones,
and may go some ways toward explaining why he finds macros
dangerous. Programmers who deploy a little more skill and
a little more care will find macros both safe and helpful.

For my info, what *is* the error in the above code? </stupid question>

--
Christopher Benson-Manica | Upon the wheel thy fate doth turn,
ataru(at)cyberspace.org | upon the rack thy lesson learn.

[Mark Gordon]

On 14 Oct 2003 09:53:41 -0700
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Da*****@cern.ch (Dan Pop) writes:

Much simpler and perfectly portable:

#define int double

*after* including all the headers. Use "signed" when you really
mean "int". Yup, the standard allows it!

Really? Then the following should also be allowed, but GCC
chokes on it:

#include <stddef.h>

#define void

int main(void) {
int *p = NULL;
return 0;
}

Depending on how NULL is defined that could expand to

int main() {
int *p = (*)0;
return 0;
}

which I would not expect to be valid.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

[Eric Sosman]

Christopher Benson-Manica wrote:

Eric Sosman <Er*********@sun.com> spoke thus:

"E. Robert Tisdale" wrote:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous -- in the wrong
hands, as are all C constructs. The error in the example
above suggests that ERT's hands may not be the right ones,
and may go some ways toward explaining why he finds macros
dangerous. Programmers who deploy a little more skill and
a little more care will find macros both safe and helpful.

For my info, what *is* the error in the above code? </stupid question>

Look very closely at the moduleName_FAILURE definition.

--
Er*********@sun.com

[Ben Pfaff]

Mark Gordon <sp******@flash-gordon.me.uk> writes:

On 14 Oct 2003 09:53:41 -0700
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Da*****@cern.ch (Dan Pop) writes:

Much simpler and perfectly portable:

#define int double

*after* including all the headers. Use "signed" when you really
mean "int". Yup, the standard allows it!

Really? Then the following should also be allowed, but GCC
chokes on it:

#include <stddef.h>

#define void

int main(void) {
int *p = NULL;
return 0;
}

Depending on how NULL is defined that could expand to

int main() {
int *p = (*)0;
return 0;
}

which I would not expect to be valid.

Follow along, please: that's the point. Dan claimed that
#define'ing a keyword is portable as long as it is done after
header inclusion. I said it's not and showed an example.
--
"When in doubt, treat ``feature'' as a pejorative.
(Think of a hundred-bladed Swiss army knife.)"
--Kernighan and Plauger, _Software Tools_

[Ben Pfaff]

Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

Eric Sosman <Er*********@sun.com> spoke thus:

"E. Robert Tisdale" wrote:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous -- in the wrong
hands, as are all C constructs. The error in the example
above suggests that ERT's hands may not be the right ones,
and may go some ways toward explaining why he finds macros
dangerous. Programmers who deploy a little more skill and
a little more care will find macros both safe and helpful.

For my info, what *is* the error in the above code? </stupid question>

1. it doesn't define SUCCESS but it does reference it.
2. The TRUE as !FALSE "trick" is pointless, since !0 == 1.
3. I haven't ever run into any C code that TRUE and FALSE really
clarified.
4. Shouldn't moduleName_OK have some moduleName_NOTOK
counterpart?
--
Christopher Benson-Manica | Upon the wheel thy fate doth turn,
ataru(at)cyberspace.org | upon the rack thy lesson learn.

A 20-line signature is clearly too long.
--
"The expression isn't unclear *at all* and only an expert could actually
have doubts about it"
--Dan Pop

[Irrwahn Grausewitz]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Eric Sosman <Er*********@sun.com> spoke thus:

"E. Robert Tisdale" wrote:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0 ^^^^^^^^^^^^^^^^^^ #define moduleName_FAILURE (!(SUCCESS))

^^^^^^^

[...] The error in the example above [...]

For my info, what *is* the error in the above code? </stupid question>

Regards
--
Irrwahn
(ir*******@freenet.de)

[Arthur J. O'Dwyer]

On Tue, 14 Oct 2003, Ben Pfaff wrote:

Mark Gordon <sp******@flash-gordon.me.uk> writes:

Ben Pfaff <bl*@cs.stanford.edu> wrote:

Da*****@cern.ch (Dan Pop) writes:
> Much simpler and perfectly portable:
>
> #define int double
>
> *after* including all the headers. Use "signed" when you really
> mean "int". Yup, the standard allows it!

#include <stddef.h>
#define void
int main(void) {
int *p = NULL;
return 0;
}

[expands to:] int *p = (*)0;

Follow along, please: that's the point. Dan claimed that
#define'ing a keyword is portable as long as it is done after
header inclusion. I said it's not and showed an example.

Well, really Dan only said that

#define int double

was portable (as long as, etc). So you could have given a
counterexample to *that* statement, instead of the general
case (which I'm sure Dan considered). Can constant expressions
contain casts? In that case,

#define NULL ((void*)((int)1-1))

could break Dan's *actual* suggestion, as well. Or even

#define NULL ((void *)(sizeof(int)-sizeof(int)))

which I *know* is a correct definition of NULL (don't I?).

-Arthur

[Christopher Benson-Manica]

Ben Pfaff <bl*@cs.stanford.edu> spoke thus:

A 20-line signature is clearly too long.

My apologies - my newsreader complains when I have more quoted text than new
text, and I felt that more than one line of context was appropriate...

--
Christopher Benson-Manica | Upon the wheel thy fate doth turn,
ataru(at)cyberspace.org | upon the rack thy lesson learn.

[Dave Vandervies]

In article <Pi***********************************@unix48.andr ew.cmu.edu>,
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote:

On Tue, 14 Oct 2003, Ben Pfaff wrote:

Follow along, please: that's the point. Dan claimed that
#define'ing a keyword is portable as long as it is done after
header inclusion. I said it's not and showed an example.

Well, really Dan only said that

#define int double

was portable (as long as, etc). So you could have given a
counterexample to *that* statement, instead of the general
case (which I'm sure Dan considered). Can constant expressions
contain casts? In that case,

#define NULL ((void*)((int)1-1))

could break Dan's *actual* suggestion, as well. Or even

#define NULL ((void *)(sizeof(int)-sizeof(int)))

which I *know* is a correct definition of NULL (don't I?).

I don't see the #define that Dan suggested breaking this. After expanding
the "int" macro, it would become:
#define NULL ((void *)(sizeof(double)-sizeof(double)))
sizeof(double) will have the same value (of type size_t) both places it
occurs, so this is still casting an integer constant expression with
value 0 to void *, and is no less a valid definition of NULL if "int"
means double than if "int" means int.

Can an implementation legally define macros that rely on int really
meaning int? I think your first example is valid, and in this case
Dan's #define will break code that uses it.

Alternately, either the programmer isn't allowed to define preprocessor
macros with the same names as type names (perhaps all keywords?), or the
implementation really should do something like "typedef void *__voidptr"
and use a cast to __voidptr in NULL (and do something similar for other
type names it uses in macros) instead of using type names that the
programmer is allowed to mangle.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Uh-huh. And a criticism of computers is that they manipulate numbers without
feeling, and a criticism of humans is that they are bipeds that eat and make
little bipeds. --Peter Seebach in comp.lang.c

[Richard Bos]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Richard Bos wrote:

So, erm... please explain how, exactly,

enum predefined_values {no, yes};

is any less namespace-polluting than

#define NO 0
#define YES 1

> cat main.c

#include<stdio.h>
#define NO 0
#define YES 1

int main(int argc, char* argv[]) {
int YES = 1;

This is a stupid idea...
return 0;
}

> gcc -Wall -std=c99 -pedantic -O2 -o main main.c main.c: In function `main':
main.c:7: parse error before numeric constant

....for which you get an error. Not a very cryptic error, either.

> cat main.c

#include<stdio.h>
typedef enum answer { NO, YES } answer;

int main(int argc, char* argv[]) {
int YES = 1;

This is an equally stupid idea...
return 0;
}

> gcc -Wall -std=c99 -pedantic -O2 -o main main.c

main.c: In function `main':
main.c:7: warning: unused variable `YES'

....for which you don't even get an error.

Richard

[Dan Pop]

In <87************@pfaff.stanford.edu> Ben Pfaff <bl*@cs.stanford.edu> writes:

Da*****@cern.ch (Dan Pop) writes:

Much simpler and perfectly portable:

#define int double

*after* including all the headers. Use "signed" when you really mean
"int". Yup, the standard allows it!
Really?

Really! Try to find a chapter and verse prohibiting it! The only such
prohibition is explicitly related to standard header inclusion:

7.1.2 Standard headers
....
4 ... The program shall not have any macros with names lexically
identical to keywords currently defined prior to the inclusion.
^^^^^^^^^^^^^^^^^^^^^^
Such a specification would be completely superfluous in the library
clause if the language prohibited the definition of such macros. Instead,
the standard explicitly says:

6.4.1 Keywords
....
2 The above tokens (case sensitive) are reserved (in translation
^^^^^^^^^^^^^^
phases 7 and 8) for use as keywords, and shall not be used
^^^^^^^^^^^^^^
otherwise.
Then the following should also be allowed, but GCC
chokes on it:

#include <stddef.h>

#define void

int main(void) {
int *p = NULL;
return 0;
}

You can't prove anything about the C standard by invoking the behaviour
of one implementation.

This is a known problem with the C standard and it poses a problem
to implementors who want to get it right: they can't use *any*
keywords in their macro definitions, they have to replace them by
reserved identifiers. A *correct* <stddef.h> would have to contain
code like this:

#ifndef __VOID
typedef void __void;
#define __VOID
#endif

#ifndef NULL
#define NULL ((__void *)0)
#endif

The typedef is safe, because void can't be a macro at the time a standard
header is included and __void is an unconditionally reserved identifier.

In this particular case, it's much easier to define NULL as a plain 0 and
get rid of all the complications, but there are other standard macros
that must be carefully defined to survive this kind of abuse.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Jun Woong]

"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message news:bm**********@rumours.uwaterloo.ca...
[...]

Alternately, either the programmer isn't allowed to define preprocessor
macros with the same names as type names (perhaps all keywords?), or the
implementation really should do something like "typedef void *__voidptr"
and use a cast to __voidptr in NULL (and do something similar for other
type names it uses in macros) instead of using type names that the
programmer is allowed to mangle.

The latter, which makes it very tricky to implement the standard
library corretly. One of the problems is that it's possible for
"sizeof" to be masked with macros in which case typedef doesn't work.
--
Jun, Woong (mycoboco at hanmail.net)

[Dan Pop]

In <bm**********@news.hananet.net> "Jun Woong" <my******@hanmail.net> writes:

"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message news:bm**********@rumours.uwaterloo.ca...
[...]

Alternately, either the programmer isn't allowed to define preprocessor
macros with the same names as type names (perhaps all keywords?), or the
implementation really should do something like "typedef void *__voidptr"
and use a cast to __voidptr in NULL (and do something similar for other
type names it uses in macros) instead of using type names that the
programmer is allowed to mangle.

The latter, which makes it very tricky to implement the standard
library corretly.

Well, the implementor can "shadow" each keyword by an alias with the same
name, but prefixed by a double underscore and use the aliases in the
standard headers.

The things get hairy only for people trying to provide "portable"
implementations of the standard library, because they can't afford this
luxury. The standard types can be easily typedef'ed to reserved
identifiers, but there is no similar workaround for the other keywords.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Jun Woong]

"Dan Pop" <Da*****@cern.ch> wrote in message news:bm***********@sunnews.cern.ch...

In <bm**********@news.hananet.net> "Jun Woong" <my******@hanmail.net> writes:

"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message news:bm**********@rumours.uwaterloo.ca...
[...]

Alternately, either the programmer isn't allowed to define preprocessor
macros with the same names as type names (perhaps all keywords?), or the
implementation really should do something like "typedef void *__voidptr"
and use a cast to __voidptr in NULL (and do something similar for other
type names it uses in macros) instead of using type names that the
programmer is allowed to mangle.

The latter, which makes it very tricky to implement the standard
library corretly.

Well, the implementor can "shadow" each keyword by an alias with the same
name, but prefixed by a double underscore and use the aliases in the
standard headers.

It's doubtful how many implementations provide such built-in "shadows"
and how many implementers even know that they should not use keywords
in implementing macros for the standard library. In this sense, it's
surely tricky, and I'd be happy if the committee decides to prohibit
masking keywords.

The things get hairy only for people trying to provide "portable"
implementations of the standard library, because they can't afford this
luxury. The standard types can be easily typedef'ed to reserved
identifiers, but there is no similar workaround for the other keywords.

One important example is sizeof, as I mentioned, which is an operator
and very useful when making macros for some standard functions imitate
the functions' behavior more well.
--
Jun, Woong (mycoboco at hanmail.net)

[Dan Pop]

In <bm**********@news.hananet.net> "Jun Woong" <my******@hanmail.net> writes:

"Dan Pop" <Da*****@cern.ch> wrote in message news:bm***********@sunnews.cern.ch...

In <bm**********@news.hananet.net> "Jun Woong" <my******@hanmail.net> writes:

>"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message news:bm**********@rumours.uwaterloo.ca...
>[...]
>>
>> Alternately, either the programmer isn't allowed to define preprocessor
>> macros with the same names as type names (perhaps all keywords?), or the
>> implementation really should do something like "typedef void *__voidptr"
>> and use a cast to __voidptr in NULL (and do something similar for other
>> type names it uses in macros) instead of using type names that the
>> programmer is allowed to mangle.
>>
>
>The latter, which makes it very tricky to implement the standard
>library corretly.

Well, the implementor can "shadow" each keyword by an alias with the same
name, but prefixed by a double underscore and use the aliases in the
standard headers.

It's doubtful how many implementations provide such built-in "shadows"
and how many implementers even know that they should not use keywords
in implementing macros for the standard library. In this sense, it's
surely tricky, and I'd be happy if the committee decides to prohibit
masking keywords.

OTOH, the built-in "shadows" provide a very simple solution to the
problem, once the implementor is aware of the problem.

I would be happy too to see the keywords as fully reserved identifiers,
but it is obvious that the committee members *deliberately* decided
otherwise and you know as well as myself how reluctant they are to
reverse their decisions...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de