By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,883 Members | 955 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,883 IT Pros & Developers. It's quick & easy.

Using explicitly sized variables in functions as auto variables or parameters

P: n/a
Hello.
Is the statement below proved by the ANSI C standard?
"It is undesirable to use explicitly sized variables in functions as
auto variables or parameters. The values will always be stored as the
processor native word size, and extra code will be generated by the
compiler to mask off bits that are not significant in the result."

Adel

Nov 14 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a


Adel wrote:
Hello.
Is the statement below proved by the ANSI C standard?
"It is undesirable to use explicitly sized variables in functions as
auto variables or parameters. The values will always be stored as the
processor native word size, and extra code will be generated by the
compiler to mask off bits that are not significant in the result."


If by "explicitly sized variable" you mean types like
int8_t or uint_least32_t, then no: The Standard describes
how these types must behave, but does not specify how the
implementation produces the behavior. In particular, it
does not specify that extra code will be generated, nor
that the values will be stored in a "native" word size.

If by "explicitly sized variable" you mean something
else, I need you to explain it to me.

Advice: Use things like int_fast16_t when your program
needs the services they provide, and don't fret about micro-
optimizing UNTIL AND UNLESS you have measurements that show
it to be necessary. "Premature optimization is the root
of all evil."

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

Nov 14 '05 #2

P: n/a
Eric Sosman wrote:
Adel wrote:
Is the statement below proved by the ANSI C standard?
"It is undesirable to use explicitly sized variables in functions as
auto variables or parameters. The values will always be stored as the
processor native word size, and extra code will be generated by the
compiler to mask off bits that are not significant in the result."


If by "explicitly sized variable" you mean types like
int8_t or uint_least32_t, then no: The Standard describes
how these types must behave, but does not specify how the
implementation produces the behavior. In particular, it
does not specify that extra code will be generated, nor
that the values will be stored in a "native" word size.

If by "explicitly sized variable" you mean something
else, I need you to explain it to me.

Advice: Use things like int_fast16_t when your program
needs the services they provide, and don't fret about micro-
optimizing UNTIL AND UNLESS you have measurements that show
it to be necessary. "Premature optimization is the root
of all evil."


In fact such actions as masking off a long to 32 bits, or a char to
8 bits, are very likely to be automatically optimized away by the
code generator when unnecessary.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #3

P: n/a
On 16 Mar 2005 08:40:58 -0800, "Adel" <ta***@pisem.net> wrote in
comp.lang.c:
Hello.
Is the statement below proved by the ANSI C standard?
The C standard does not prove anything. It neither needs to nor
attempts to.
"It is undesirable to use explicitly sized variables in functions as
The word "undesirable" does not appear in the C standard.
auto variables or parameters. The values will always be stored as the
The standard says nothing at all about how objects are laid out in
memory, let alone any "always" about them.
processor native word size, and extra code will be generated by the
compiler to mask off bits that are not significant in the result."

Adel


If you want proof for a non-technical, opinionated statement that, if
it can be answered at all, can only be answered for specific
implementations on specific architectures, I would suggest you ask the
person who made the statement to provide it.

Tell them to put up or shut up, in other words.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.