what's wrong with the macro

[DaVinci]

#include<stdio. h>
#include<stdlib .h>
#include<string .h>

#define SECONDS_PER_YEA R (60*60*24*365)U L
int main()
{
unsigned long int u_i = SECONDS_PER_YEA R;
printf("%lu\n", u_i);

return 0;
}
cc -g -c -Wall -std=c99 -DDEBUG define.c
define.c: In function 'main':
define.c:17: error: expected ',' or ';' before 'UL'
make: *** [define.o] error 1

[Keith Thompson]

"Giorgio Silvestri" <gi************ **@libero.itwri tes:

"Keith Thompson" <ks***@mib.orgh a scritto nel messaggio
news:ln******** ****@nuthaus.mi b.org...

[...]

>You want parentheses around the second defintion:

#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Probably:

#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL))

is better :-)

Um, yeah, thanks for catching that.

--
Keith Thompson (The_Other_Keit h) 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.

[Keith Thompson]

Frederick Gotham <fg*******@SPAM .comwrites:

Keith Thompson posted:

>You want parentheses around the second defintion:

#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Consider "sizeof SECONDS_PER_YEA R".

I don't understand... what could that have parsed to?

Frederick, I don't want to leave you waiting for a response from me,
so I'll remind you of this:

<http://groups.google.c om/group/comp.lang.c/msg/a03c532b26664ed 4>

--
Keith Thompson (The_Other_Keit h) 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.

[pete]

Keith Thompson wrote:

>
"Giorgio Silvestri" <gi************ **@libero.itwri tes:

"Keith Thompson" <ks***@mib.orgh a scritto nel messaggio
news:ln******** ****@nuthaus.mi b.org...

[...]

You want parentheses around the second defintion:

#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Probably:

#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL))

is better :-)

Um, yeah, thanks for catching that.

What is the cast for?

--
pete

[Walter Roberson]

In article <45***********@ mindspring.com> ,
pete <pf*****@mindsp ring.comwrote:

>"Giorgio Silvestri" <gi************ **@libero.itwri tes:

#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL))

>What is the cast for?

Once the constant (without the cast) is computed by the parser, it
becomes a numeric value of indeterminate width -- through some unspecified
mechanism the parser knows the minimum width needed to represent it,
but it is not specifically that minimum width and not specifically UL
and so on. If the cast-less constant were determined
to be too large to match the other operand of the expression, then
widening is going to take place. In some contexts, if the constant
were determined to be able to fit within the *signed* version of
a larger type, it would be widened to *signed* rather than to
unsigned [remember, the system knows it as a numeric value at that point,
not specifically as an unsigned numeric value.]. The (unsigned long) cast
stops any uncertainty about exactly what type is going to be there.
Now try printf("%d\n", CASTLESS_SECOND S_PER_YEAR); -- is that right?
It is if the CASTLESS_SECOND S_PER_YEAR is accomedated as a signed int,
but not if CASTLESS_SECOND S_PER_YEAR requires long on that system.
60UL * 60UL * 24UL * 365UL as a numeric value takes about 25 bits.
On a system with 32 bit int and 64 bit unsigned long,
the cast-less version it would fit within a signed int on that system
and %d would be correct and %ld would be wrong. So cast-less, the
value is not as easily portable. Add the cast and you -know- the type
and can always use %lu.
--
Programming is what happens while you're busy making other plans.

[Keith Thompson]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <45***********@ mindspring.com> ,
pete <pf*****@mindsp ring.comwrote:

>>"Giorgio Silvestri" <gi************ **@libero.itwri tes:

>#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL))

>>What is the cast for?

I believe it's superfluous.

Once the constant (without the cast) is computed by the parser, it
becomes a numeric value of indeterminate width -- through some unspecified
mechanism the parser knows the minimum width needed to represent it,
but it is not specifically that minimum width and not specifically UL
and so on. If the cast-less constant were determined
to be too large to match the other operand of the expression, then
widening is going to take place. In some contexts, if the constant
were determined to be able to fit within the *signed* version of
a larger type, it would be widened to *signed* rather than to
unsigned [remember, the system knows it as a numeric value at that point,
not specifically as an unsigned numeric value.]. The (unsigned long) cast
stops any uncertainty about exactly what type is going to be there.

I don't think so. C99 6.6p11 says:

The semantic rules for the evaluation of a constant expression are
the same as for nonconstant expressions.

The expression:

(60UL * 60UL * 24UL * 365UL)

is a constant expression, but not a constant (i.e., a literal).

A single integer literal with a UL suffix is of type unsigned long int
or unsigned long long int, depending on the value; all the constants
in the above are well within the guaranteed range of unsigned long, so
that's their type. Multiplying an unsigned long by an unsigned long
yields an unsigned long, so the entire expression is of type unsigned
long.

As it happens, the final result, 31536000, is also within the
guaranteed range of unsigned long, so there's no possibility of
overflow. But even if there were (say, if you wanted the number of
seconds in a millenium), an overflow wouldn't change the type of the
expression.

--
Keith Thompson (The_Other_Keit h) 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.

[Richard Heathfield]

Keith Thompson said:

Frederick Gotham <fg*******@SPAM .comwrites:

>Keith Thompson posted:

>>You want parentheses around the second defintion:

#define SECONDS_PER_YEA R ((unsigned long)(60UL * 60UL * 24UL * 365UL)(

Consider "sizeof SECONDS_PER_YEA R".

I don't understand... what could that have parsed to?

Frederick, I don't want to leave you waiting for a response from me,
so I'll remind you of this:

<http://groups.google.c om/group/comp.lang.c/msg/a03c532b26664ed 4>

A waste of time, Keith. If he were interested in responses from you, he'd
have apologised a long time ago.

Personally, whenever I see a question from Mr Gotham, I simply don't bother
to reply. When I see others giving him wrong answers, I don't bother to
correct them. If he wants expert assistance, he should not alienate
experts.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Walter Roberson posted:

>>What is the cast for?

Once the constant (without the cast) is computed by the parser, it
becomes a numeric value of indeterminate width -- through some unspecified
mechanism the parser knows the minimum width needed to represent it,
but it is not specifically that minimum width and not specifically UL
and so on.

Incorrect.

Multiply a UL by a UL and you get a UL.
--

Frederick Gotham

[Frederick Gotham]

Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,
I'd like to ask any other programmers to explain to me why:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

would have been undesireable.

Actually, don't bother, because I already know the answer: Keith was wrong.

The expression in question has only one possible parse, because the operand
of "sizeof" cannot be a cast expression. Therefore, the following two
expressions are exactly equivalent:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

sizeof ((unsigned long)(60UL * 60UL * 24UL * 365UL))

--

Frederick Gotham

[Frederick Gotham]

Frederick Gotham posted:

The expression in question has only one possible parse, because the
operand of "sizeof" cannot be a cast expression.

And even if it could be, there would be a syntax error.

--

Frederick Gotham

[Eric Sosman]

Frederick Gotham wrote On 10/24/06 11:23,:

Keith Thompson posted:

<snip tripe>

Richard Heathfield posted:

<snip tripe>

Since the two self-proclaimed masters of this newsgroup won't reply to me,
I'd like to ask any other programmers to explain to me why:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

would have been undesireable.

Actually, don't bother, because I already know the answer: Keith was wrong.

The expression in question has only one possible parse, because the operand
of "sizeof" cannot be a cast expression. Therefore, the following two
expressions are exactly equivalent:

sizeof (unsigned long)(60UL * 60UL * 24UL * 365UL)

sizeof ((unsigned long)(60UL * 60UL * 24UL * 365UL))

It's a funny thing, but when I tried these out on three
completely different C compilers, all three treated the two
"exactly equivalent" expressions differently. Specifically,
they all rejected the first with complaints about "syntax
error" or some such, but they all accepted the second.

Three out of three identical mistakes from independent
compiler authors -- that's too much for coincidence, don't
you think? There must be an enormous shadowy conspiracy
at work to retard progress in programming by producing and
promoting faulty C compilers! They're probably taking steps
to silence us even now; I hope I can get this posted befor

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