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!

[jameskuyper]

Richard Heathfield wrote:

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.

On the originally referenced web site, the relevant question specified
that leap years are to be ignored. The macro name should have
reflected that fact, though I'm not sure of the best way to do so.
SECONDS_PER_NON _LEAP_YEAR?

[dspfun]

On 2 Jan, 22:29, jameskuy...@ver izon.net wrote:

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().- Dölj citerad text -

- Visa citerad text -

Ok, thank you for the explanation! I believe it is the following in
C99 that specifies this (that the result of a+b will be UINT_MAX + 1
-20 + 6 = UINT_MAX-13):

2
Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or
subtracting one more than the maximum value that can be represented in
the new type
until the value is in the range of the new type.49)

[CBFalconer]

ja*********@ver izon.net wrote:

>

.... snip ...

>
On the originally referenced web site, the relevant question
specified that leap years are to be ignored. The macro name
should have reflected that fact, though I'm not sure of the
best way to do so. SECONDS_PER_NON _LEAP_YEAR?

Too long. Try SECS_PER_SQUAT_ YR. :-)

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

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:

ja*********@ver izon.net wrote:

>>

... snip ...

>>
On the originally referenced web site, the relevant question
specified that leap years are to be ignored. The macro name
should have reflected that fact, though I'm not sure of the
best way to do so. SECONDS_PER_NON _LEAP_YEAR?

Too long. Try SECS_PER_SQUAT_ YR. :-)

The term for a non-leap year is "common year".

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

[Army1987]

Keith Thompson wrote:

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

>Are suffixes allowed on expressions?

No (unless the expression happens to be an integer constant).

The suffix is *part* of the constant. They form one token.
You can't have e.g. `12 UL`.
--
Army1987 (Replace "NOSPAM" with "email")

[Charles Richmond]

CBFalconer wrote:

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.

And SECONDS_PER_YEA R really is equal to (60 * 60 * 24 * 365).
^^^^

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[dspfun]

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

[jameskuyper]

dspfun wrote:

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

'const' is a type-qualifier, and therefore a declaration-specifier.
'a' is parsed as a direct-declarator, and therefore as a declarator,
and therefore as an init-declarator-list. 6.7p1 requires that
declarations-specifiers preceed the init-declarator-list, so this is
an incorrect declaration.

[dspfun]

On 3 Jan, 21:18, jameskuy...@ver izon.net wrote:

dspfun wrote:

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

'const' is a type-qualifier, and therefore a declaration-specifier.
'a' is parsed as a direct-declarator, and therefore as a declarator,
and therefore as an init-declarator-list. 6.7p1 requires that
declarations-specifiers preceed the init-declarator-list, so this is
an incorrect declaration.

Thanks for a great answer!

How did you do the mapping type-qualifier -declaration-specifier and
direct-declarator -declarator -init-declarator-list ?

I found something more suspicuous in the anser to question 2:

"Knowledge of the ternary conditional operator. This operator exists
in C because it allows the compiler to produce more optimal code than
an if-then-else sequence. "

Is this really true?

[jameskuyper]

dspfun wrote:

On 3 Jan, 21:18, jameskuy...@ver izon.net wrote:

dspfun wrote:

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

'const' is a type-qualifier, and therefore a declaration-specifier.
'a' is parsed as a direct-declarator, and therefore as a declarator,
and therefore as an init-declarator-list. 6.7p1 requires that
declarations-specifiers preceed the init-declarator-list, so this is
an incorrect declaration.

Thanks for a great answer!

How did you do the mapping type-qualifier -declaration-specifier and

This is just a matter of reading and correctly interpreting the
productions listed in section 6.7p1.

direct-declarator -declarator -init-declarator-list ?

I left out init-declarator, between the last two items there. See
sections 6.7.5p1 and 6.7p1.

I found something more suspicuous in the anser to question 2:

"Knowledge of the ternary conditional operator. This operator exists
in C because it allows the compiler to produce more optimal code than
an if-then-else sequence. "

Is this really true?

I sincerely doubt that any modern compiler produces different code
depending upon whether if-then-else or ?: is used, and I'm quite sure
that any such minor efficiencies have nothing to do with the reason
why it exists. The ?: operator is syntactic sugar, which makes certain
construct much simpler to write. It's not necessary, but it is
occasionally convenient, and convenience should not be underrated as a
feature of a computer programming language.