Suffix allowed on expressions?

[dspfun]

Hi!

Are suffixes allowed on expressions?

For example, is the following allowed:

#define SECONDS_PER_YEA R (60 * 60 * 365) UL

I found this in a C test at http://www.embedded.com/2000/0005/0005feat2.htm
,
however, I am not able to compile when using this macro (or just the
expression "a = (60 * 60 * 365) UL;").

Where in the standard does it say that it is allowed/not allowed?

It would also be interesting to hear if there are any faults in the
other questions and answers in the test.

BRs!

[dspfun]

On 2 Jan, 19:07, dspfun <dsp...@hotmail .comwrote:

Hi!

Are suffixes allowed on expressions?

For example, is the following allowed:

#define SECONDS_PER_YEA R (60 * 60 * 365) UL

It should be:
#define SECONDS_PER_YEA R (60 * 60 * 24 * 365) UL

>
I found this in a C test athttp://www.embedded.co m/2000/0005/0005feat2.htm
,
however, I am not able to compile when using this macro (or just the
expression "a = (60 * 60 * 365) UL;").

It should be:
(or just the expression statement "a = (60 * 60 * 24 * 365) UL;")

[Ben Pfaff]

dspfun <ds****@hotmail .comwrites:

Are suffixes allowed on expressions?

No. The suffixes that you are talking about are allowed only on
integer and floating-point constants.

For example, is the following allowed:

#define SECONDS_PER_YEA R (60 * 60 * 365) UL

No. To get the apparently intended effect, you can write
#define SECONDS_PER_YEA R (60UL * 60 * 365)
or
#define SECONDS_PER_YEA R (unsigned long int) (60 * 60 * 365)
--
"All code should be deliberately written for the purposes of instruction.
If your code isn't readable, it isn't finished yet."
--Richard Heathfield

[Ben Pfaff]

Ben Pfaff <bl*@cs.stanfor d.eduwrites:

To get the apparently intended effect, you can write
#define SECONDS_PER_YEA R (60UL * 60 * 365)
or
#define SECONDS_PER_YEA R (unsigned long int) (60 * 60 * 365)

Oh, and to get the apparently intended value, you need to
multiply by an additional factor of 24.
--
char a[]="\n .CJacehknorstu" ;int putchar(int);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,0x11f6} ,*p
=b,i=24;for(;p+ =!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Ben Bacarisse]

Ben Pfaff <bl*@cs.stanfor d.eduwrites:

dspfun <ds****@hotmail .comwrites:

>For example, is the following allowed:

#define SECONDS_PER_YEA R (60 * 60 * 365) UL

No. To get the apparently intended effect, you can write
#define SECONDS_PER_YEA R (60UL * 60 * 365)
or
#define SECONDS_PER_YEA R (unsigned long int) (60 * 60 * 365)

The latter can, as I am sure you know, overflow. Since the quiz was
on a site that referenced embedded systems, it would be safer to
assume a minimal max int (if you see what I mean).

To the OP: to illustrate using a cast (which *can* be used in
expressions unlike suffixes) you could write:

#define SECONDS_PER_YEA R ((unsigned long int)60 * 60 * 365)

* is left-associative so all the multiplications must produce unsigned
long int results.

--
Ben.

[Keith Thompson]

Keith Thompson <ks***@mib.orgw rites:
[...]

There's a contact address in the article; I'll send him pointers to
your article and my followup.

The e-mail address in the article is obsolete (I think the article is
several years old). I found what appears to be his current address by
searching the embedded.com web site. (I won't post it here; I'm sure
he gets more than enough spam already.)

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Ben Pfaff wrote:

dspfun <ds****@hotmail .comwrites:

>Are suffixes allowed on expressions?

No. The suffixes that you are talking about are allowed only on
integer and floating-point constants.

>For example, is the following allowed:

#define SECONDS_PER_YEA R (60 * 60 * 365) UL

No. To get the apparently intended effect, you can write
#define SECONDS_PER_YEA R (60UL * 60 * 365)
or
#define SECONDS_PER_YEA R (unsigned long int) (60 * 60 * 365)

The second will only work if the expression (60 * 60 * 365) is
within the range of an int. This is doubtful if running on a 16
bit system.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[dspfun]

What about question 12, isn't it implementation specific since the
representation of the basic types are not precisely defined by the
language?

---------------
12. What does the following code output and why?

void foo(void)
{
unsigned int a = 6;
int b = -20;
(a+b 6) ? puts("6") : puts("<= 6");
}

Answer:
This question tests whether you understand the integer promotion rules
in C-an area that I find is very poorly understood by many developers.
Anyway, the answer is that this outputs "6." The reason for this is
that expressions involving signed and unsigned types have all operands
promoted to unsigned types. Thus ý20 becomes a very large positive
integer and the expression evaluates to greater than 6. This is a very
important point in embedded systems where unsigned data types should
be used frequently (see Reference 2). If you get this one wrong, you
are perilously close to not getting the job.
-------------

[Richard Heathfield]

dspfun said:

On 2 Jan, 19:07, dspfun <dsp...@hotmail .comwrote:

>Hi!

Are suffixes allowed on expressions?

For example, is the following allowed:

#define SECONDS_PER_YEA R (60 * 60 * 365) UL

It should be:
#define SECONDS_PER_YEA R (60 * 60 * 24 * 365) UL

The result of the above calculation will be out by 86400 seconds this year.

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

[jameskuyper]

dspfun wrote:

What about question 12, isn't it implementation specific since the
representation of the basic types are not precisely defined by the
language?

This has nothing to do with the representation of the basic types, it
depends only upon the usual arithmetic conversions. While the results
of those conversions vary from implementation to implementation, the
particular values chose for a and b below are guaranteed to produce
the same final results on all conforming implementations of C.

---------------
12. What does the following code output and why?

void foo(void)
{
unsigned int a = 6;
int b = -20;
(a+b 6) ? puts("6") : puts("<= 6");
}

Answer:
This question tests whether you understand the integer promotion rules
in C-an area that I find is very poorly understood by many developers.
Anyway, the answer is that this outputs "6." The reason for this is
that expressions involving signed and unsigned types have all operands
promoted to unsigned types. ...

Note that this is not the correct rule in C99, though I think it's a
correct statement of the C90 rule. In C99, the signed operand is
converted to the type of the unsigned operand only if the rank of the
unsigned type is greater than or equal to the rank of the signed type.
In this case, that happens to be true.

... Thus �20 becomes a very large positive
integer and the expression evaluates to greater than 6. ...

Specifically, (a+b) has a value of UINT_MAX-13. The value of that sum
depends upon the implementation, since UINT_MAX depends upon the
implementation. However, since UINT_MAX must be at least 65535, that
value is guaranteed to be at least 65522, and therefore greater than
6, and the routine is guaranteed to pass "6" to puts().