|
|
|
|
|
|
| Author |
Message |
Lawrence Kirby
*nix forums Guru
Joined: 23 Feb 2005
Posts: 516
|
 Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
On Wed, 02 Feb 2005 02:10:09 +0000, CBFalconer wrote:
| Quote: | lawrence.jones@ugs.com wrote:
In comp.std.c CBFalconer <cbfalconer@yahoo.com> wrote:
It would suffice to say that any bitfield is treated as having the
specified type for any further operations.
It would also be completely wrong. See DR 122:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_122.html
As you may have gathered from my previous postings, I am deeply
opposed to that. It obviously isn't officially incorporated into
the standard, and doing so would be a mistake.
|
Unfortunately there is just too much else in the standard that depends on
bit-field width being considered as a part of the type. Consider for
example assigning an out of range value to an unsigned bit-field in the
context of 6.3.1.3p2.
| Quote: | There have been
several instances posted in this thread (at least on c.l.c) where
that action leaves the poor programmer in a quandary as to what the
code will do on another machine. One example is the 16 bit
unsigned field, which will be interpreted differently on a 32 bit
and on a 16 bit int machine.
|
That's an example of the problem with the overall value-preserving
rules, not just bit-fields. You have no argument from me that
unsigned-preserving rules would have been much better for the language.
But that's not what we have and trying to make bit-fields unsigned
preserving while char and short promotions remain value preserving is
probably not a good idea.
| Quote: | I came to this conclusion from first principles by considering the
rational code generation actions, all elaborated elsewhere in this
thread. This also provides the known treatment from the point of
the language user.
|
Whether you use value or unsigned preserving rules doesn't make any
difference to code generation for the promotion. In both cases the result
of promoting an unsigned value is a positive value which has the same
representation in a signed or unsigned int type.
Lawrence |
|
| Back to top |
|
 |
Chris Croughton
*nix forums Guru
Joined: 19 Feb 2005
Posts: 420
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: what is the prog coding for this question and what it output
|
|
|
On Wed, 02 Feb 2005 11:06:44 +0000, Lawrence Kirby
<lknews@netactive.co.uk> wrote:
| Quote: | On Tue, 01 Feb 2005 18:24:36 +0000, Chris Croughton wrote:
For that matter a number of Unix systems have
fixed-size stacks per process (and even one which isn't thought of as
fixed size will have a limit in practice, even if it's several
gigabytes).
There are differences between a fixed sized stack and a variable stack
with a size limit. E.g. in implementations where, say, "stack" grown down
from the top of the address space and "heap" grows up from the bottom, if
a program uses less "stack" space than it is allowed it may be able to use
the extra for "heap" allocation. There there is the question of whether
memory for the fixed sized stack is pre-allocated.
|
Yes, the stacks which share a data area are a different problem (and one
that's harder to predict, because it depends on the dynamic size of the
'heap'). The program may run fine sometimes and not others. That's why
with embedded systems the stacks are generally not shared with anything
else, so that the behaviour is predictable (the same often goes for
dynamic memory, it's allocated in fixed areas or 'pools' of fixed size,
to avoid fragmentation problems).
Chris C |
|
| Back to top |
|
|
Martin Schöön
*nix forums Guru
Joined: 22 Feb 2005
Posts: 2122
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:420096C4.36C74798@yahoo.com...
[snip]
| Quote: | One ridiculous result of this attitude is that a 1 bit field,
whether declared as int or unsigned int, would always be treated as
-1 or 0.
|
No! An unsigned 1 bit bit-field can (obviously) hold the values 0 and 1.
"Value preserving" promotion should result in a signed int with the same
value (otherwise "value preserving" would be a pretty stupid name).
In code generation terms, you only copy/move the sign bit when the
unpromoted type is signed, not when the promoted type is signed. Perhaps
this example exposes the root of your misunderstanding.
Alex |
|
| Back to top |
|
|
David. E. Goble
*nix forums beginner
Joined: 16 Feb 2005
Posts: 2
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Arrh, something else is wrong! With almost identical code snipets to working code.
|
|
|
On Tue, 01 Feb 2005 23:59:37 -0500, bd <bdonlan@gmail.com> wrote:
| Quote: | David. E. Goble wrote:
On Mon, 31 Jan 2005 19:57:11 -0600, "j" <jake30NOSPAM@bellsouth.net
wrote:
"David. E. Goble" <degoble@gtech.computing> wrote in message
news:66ntv0l5dr22hkdnq41o0b9foshmbds0dm@4ax.com...
Is there some sort of limitation or something.... Because one second
something will work the next thing its not!
In ``therest'', line 53, you have the following,
fprintf(*header, "if (%si<%scounter)\n", b,b);
Well the outputed text in all files is what was expected, namely;
if(avatarsi<avatarscounter)
if(smilesi<smilesscounter)
if(sigssi<sigscounter)
Nonetheless I did change it too;
char temp[LINESIZE];
....
strcpy(temp, b);
strcat(temp, "i<");
fprintf(*header, "if (%s%scounter)\n", temp, b);
No need to do that. Just:
fprintf(*header, "if(%si<%scounter)\n", b, b);
|
But, for some reason the output: if (sigsi<sigscounter)
Which is then converted to js: document.writeln("if
(sigsi<sigscounter)");
Does causes the the previous and next buttons to fail.
here is a link to the current working version;
http://home.insightbb.com/~bow.foggy/sigs/
Regards David. E. Goble
http://www.pnc.com.au/~degoble
degoble[AT]pnc.com.au | dgoble[AT]pnc.com.au
Po Box 648 (9 Murray St), Kingscote, Kangaroo Island SA 5223 |
|
| Back to top |
|
|
Eric Sosman
*nix forums Guru
Joined: 21 Feb 2005
Posts: 1246
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: function to count number of set bits
|
|
|
Lawrence Kirby wrote:
| Quote: | On Tue, 01 Feb 2005 11:44:36 -0500, Eric Sosman wrote:
CBFalconer wrote:
Look at the way INT_MIN is usually defined [...]
Note that `(int)-32768' wouldn't work, since the value
must be a constant expression and constant expressions can't
contain cast operators.
Casts are allowed in constant expressions although there are some
restrictions which don't apply here. The problem with (int)-32768 where
INT_MAX is 32767 and UINT_MAX is 65535 is that it is equivalent to
(int)(32768U) i.e. you are trying to convert to a signed integer type a
value that is not representable in that type. That's undefined in C90 and
in C99 you get an implementation-defined value or signal.
|
Sorry; sloppy language on my part. Casts are indeed
permitted in "constant expressions" (6.6), but they are
forbidden in the special form of "constant expression" the
preprocessor can evaluate (6.10.1). INT_MIN and friends
must be evaluable by the preprocessor (5.2.4.2.1), and so
cannot be defined with casts.
--
Eric Sosman
esosman@acm-dot-org.invalid |
|
| Back to top |
|
|
Lawrence Kirby
*nix forums Guru
Joined: 23 Feb 2005
Posts: 516
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
On Wed, 02 Feb 2005 13:02:08 +0000, Alex Fraser wrote:
| Quote: | "CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:420096C4.36C74798@yahoo.com...
[snip]
One ridiculous result of this attitude is that a 1 bit field,
whether declared as int or unsigned int, would always be treated as
-1 or 0.
No! An unsigned 1 bit bit-field can (obviously) hold the values 0 and 1.
"Value preserving" promotion should result in a signed int with the same
value (otherwise "value preserving" would be a pretty stupid name).
|
To be honest it is. Any promotion mechanism that didn't preserve value
would be rather silly. Unsigned preserving promotion also preserves value.
So preserving value is not a distinguishing feature of the standard's
integer promotions.
Lawrence |
|
| Back to top |
|
|
Daniel Vallstrom
*nix forums beginner
Joined: 11 Mar 2005
Posts: 16
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: eliminating unreferenced parameter warnings
|
|
|
John Fisher wrote:
| Quote: | void f(int p)
{
}
Many (most?) compilers will report that p is unreferenced here. This
may not
be a problem as f may have to match some common prototype. Typically
pointers to functions are involved.
For a long time I have used
#define UNUSED(p) ((void)(p))
so that
void f(int p)
{
UNUSED(p);
}
will not cause a warning on all compilers I have tried it with.
However a
third party code vendor uses
#define UNUSED(p) { (p) = (p); }
I believe this code has been ported to many different compilers. On
my
compiler this will produce a useless assignment warning, so for that
reason
I obviously prefer my approach.
What's your favourite trick and why? Which approach do you think is
more
likely to prevent a warning? Has anyone done a survey?
|
This is indeed not an uncommon problem.
If you only care about suppressing warnings from compilers that support
an attribute to parameters, I prefer using those compiler specific
attributes. For example you would write:
int constantEvil( int dummyArg attribute__(unused) ) { return 666; }
where attribute__ is defined something like this:
#ifdef __GNUC__
#define attribute__(a) __attribute__ ((a))
#else
#define attribute__(a)
#endif
Altering the program as such by adding spurious statements like (void)x
or x=x feels ugly regardless of the issue that it might not be
effective.
Daniel Vallstrom |
|
| Back to top |
|
|
Kevin Bracey
*nix forums beginner
Joined: 21 Feb 2005
Posts: 43
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
In message <pan.2005.02.01.19.12.19.906000@netactive.co.uk>
Lawrence Kirby <lknews@netactive.co.uk> wrote:
| Quote: | On Tue, 01 Feb 2005 13:20:49 +0000, Kevin Bracey wrote:
17-bit bitfields are not permitted on 16-bit systems, so the only issue
is that 16-bit ones promote differently to smaller ones. Just like
unsigned short promoting differently to unsigned char.
The standard says in 6.7.21p4
"A bit-field shall have a type that is a qualified or unqualified version
of _Bool, signed
int, unsigned int, or some other implementation-defined type."
So if an implementation supports, say, long and unsigned long bit-fields
as implementation-defined types what constraints on the implementation of
those does the standard specify?
|
Such things are not subject to integer promotions, according to 6.3.1.1p2.
It doesn't seem terribly concrete, but I think that may mean that a "long:4"
just functions as a long? What about a "unsigned char:4"? Does it act as a
unsigned char, and hence get promoted?
Ew. Bitfields on larger types are not something I'm familiar with, as our
systems don't support it.
--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/ |
|
| Back to top |
|
|
James Kuyper
*nix forums beginner
Joined: 16 Feb 2005
Posts: 13
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
CBFalconer wrote:
| Quote: | Alex Fraser wrote:
"CBFalconer" <cbfalconer@yahoo.com> wrote in message
lawrence.jones@ugs.com wrote:
....
It would also be completely wrong. See DR 122:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_122.html
....
The wording of the standard is easily understood for types subject
to integer promotion other than bit-fields, and defines different
behaviour to what you suggest should apply to bit-fields. I believe
the intention was for the two to be consistent - bit-fields should
be viewed as a "small" type like unsigned char and unsigned short -
and this agrees with the response to the defect report.
....
One ridiculous result of this attitude is that a 1 bit field,
whether declared as int or unsigned int, would always be treated as
-1 or 0. This is contrary to the usual C practice. The
|
This "attitude" (correct interpretation of the standard, as confirmed by
the Committee's decision on DR 122), calls for value-preserving
conversion of the 1 bit field to int. Therefore, if it's declared as
unsigned, the result must be either 0 or 1, not -1.
| Quote: | opportunity exists to ensure that booleans stored in bit fields are
properly expanded. Or should we have to write !!x for any boolean
x stored in a bitfield?
|
"If the value 0 or 1 is stored into a nonzerowidth bit-field of type
_Bool, the value of the bit-field shall compare equal to the value stored."
The value-preserving conversion to int can therefore only produce a 0 or
a 1. |
|
| Back to top |
|
|
CBFalconer
*nix forums Guru
Joined: 09 Mar 2005
Posts: 2502
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
Tony Finch wrote:
| Quote: | CBFalconer <cbfalconer@yahoo.com> wrote:
.... snip ...
Simple - signed preservation leads to consistent interpretation by
the user, minimization of generated code, and reduction of code in
the code generator. Due to the ambiguity of the present standard
the opportunity exists to specify this correctly. Do so.
That would be to reverse a decision made over 15 years ago. If you
want K&R C you know where to find it...
|
No such decision has been embodied in the standard, so it doesn't
count.
--
"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 |
|
| Back to top |
|
|
CBFalconer
*nix forums Guru
Joined: 09 Mar 2005
Posts: 2502
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
Lawrence Kirby wrote:
| Quote: | On Wed, 02 Feb 2005 02:10:09 +0000, CBFalconer wrote:
lawrence.jones@ugs.com wrote:
In comp.std.c CBFalconer <cbfalconer@yahoo.com> wrote:
It would suffice to say that any bitfield is treated as having the
specified type for any further operations.
It would also be completely wrong. See DR 122:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_122.html
As you may have gathered from my previous postings, I am deeply
opposed to that. It obviously isn't officially incorporated into
the standard, and doing so would be a mistake.
Unfortunately there is just too much else in the standard that
depends on bit-field width being considered as a part of the type.
Consider for example assigning an out of range value to an unsigned
bit-field in the context of 6.3.1.3p2.
|
For this purpose that is just one more black cat in the dark. The
values are known to be positive, and the standard insists on binary
representation, so masking off a set of less significant bits
produces the same answer for all three flavors. All that has to be
done is make a conversion to some form of unsigned (if needed) in
the original, not in the potential 30 odd or more types pseudo
created by bit fields.
--
"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 |
|
| Back to top |
|
|
James Kuyper
*nix forums beginner
Joined: 16 Feb 2005
Posts: 13
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
CBFalconer wrote:
| Quote: | Tony Finch wrote:
....
That would be to reverse a decision made over 15 years ago. If you
want K&R C you know where to find it...
No such decision has been embodied in the standard, so it doesn't
count.
|
The decision merely confirmed a meaning that was already (albeit
unclearly) embodied in the standard. |
|
| Back to top |
|
|
Kevin Bracey
*nix forums beginner
Joined: 21 Feb 2005
Posts: 43
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: eliminating unreferenced parameter warnings
|
|
|
In message <87r7jzr3nf.fsf@benpfaff.org>
Ben Pfaff <blp@cs.stanford.edu> wrote:
| Quote: | Clark S. Cox III <clarkcox3@gmail.com> writes:
I typically just delete the parameter name if I'm not actually using it:
void f(int)
{
}
That's not C.
|
Bloomin' well should be though. Just the sort of simple improvement that C++
introduced that is worth adopting.
--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/ |
|
| Back to top |
|
|
Clark S. Cox III
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 173
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: eliminating unreferenced parameter warnings
|
|
|
On 2005-02-01 23:23:32 -0500, Ben Pfaff <blp@cs.stanford.edu> said:
| Quote: | Clark S. Cox III <clarkcox3@gmail.com> writes:
I typically just delete the parameter name if I'm not actually using it:
void f(int)
{
}
That's not C.
|
Ack, sorry, wrong group.
--
Clark S. Cox, III
clarkcox3@gmail.com |
|
| Back to top |
|
|
Daniel Vallstrom
*nix forums beginner
Joined: 11 Mar 2005
Posts: 16
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Learning C with Older books ?.
|
|
|
Tim Rentsch wrote:
| Quote: | Dan.Pop@cern.ch (Dan Pop) writes:
|
[snip discussion about the pros and cons of gcc's -W and -Wall warning
options]
| Quote: | So, what's wrong with -Wall, from your point of view?
Ok, the $64 question. Again for the sake of discussion let's take
the list below as the set of warnings covered by -Wall:
-Wchar-subscripts - using values of type 'char' to subscript
-Wcomment - when /* appears in a comment string (& more)
-Wformat - check printf et al format strings against args
-Wnonnull - NULL arg to "nonnull" attribute parameters
-Wimplicit - decl w/o type, or function call w/o decl
-Wmain - type of main() is suspicious
-Wmissing-braces - initializers not fully bracketed
-Wparentheses - eg, if(x=a+b). also, some unpaired if's
-Wsequence-point - possible violations of sequence point rules
-Wreturn-type - non-void function 'return;'; no function type
-Wswitch - switch( ENUM ) that doesn't cover all cases
-Wswitch-default - switch() w/o 'default:' case
-Wswitch-enum - switch( ENUM ) cases != ENUM values
-Wtrigraphs - if any trigraphs are encountered
-Wunused - unused variable, value, label, static function
-Wunused-parameter - unused parameter
-Wuninitialized - variable might be used without having been set
-Wunknown-pragmas - unrecognized #pragma
-Wstrict-aliasing - code that may break with -fstrict-aliasing
I realize this set probably doesn't exactly match the gcc that anyone
is currently using, but I think it will help the discussion if we
proceed under the assumption that these conditions make up the current
set of -Wall conditions.
I would break these down into four categories - the always useful, the
usually useful, the probably useful, and the objectionable.
|
[snip]
| Quote: | The 'objectionable' are those that might get used as diagnostic tools
from time to time but are turned off during all regular compiles. The
objectionable ones are:
-Wparentheses - eg, if(x=a+b). also, some unpaired if's
-Wswitch-default - switch() w/o 'default:' case
Discussion for -Wswitch-default:
-Wswitch-default
Warn whenever a "switch" statement does not have a
"default" case.
First of all, either -Wswitch or -Wswitch-enum seems like a more
accurate diagnostic tool when the switch() expression is of an
enumerated type [2].
Second, the decision to put in a 'default:' case is a programming
practice that is appropriate in some circumstances but not in others.
Apparently there is no way to locally override the warning for
switch() statements where the 'default:' is judged better left out.
Third, automatically adding a 'default:' to every switch() can reduce
the value of -Wswitch/-Wswitch-enum. It can be useful to leave off
the 'default:' so that when additional values are added to an
enumerated type then switch() statements on values of that type will
be flagged. Including -Wswitch-default will thwart this programming
practice.
|
All good points. However, obviously "-Wswitch-default is included in
-Wall" from the gcc documentation means that -Wswitch-default is *not*
included in -Wall;p JK But in fact it seems to be the case that
-Wswitch-default is indeed not included in -Wall --- thankfully. Testing
it I get no warnings when using the -Wall flag while I get tons of
warnings when I explicitly add the -Wswitch-default flag.
Here is an old post to this thread that I made through google that
doesn't seem to show up in any of the non-google news-readers I use.
(Not that you missed much if you haven't received it;)
http://groups-beta.google.com/group/alt.comp.lang.learn.c-c++/browse_frm/thread/66bc74d8d8d22b33/6bbce6900ea6d6e4?q=vallstrom&_done=%2Fgroups%3Fq%3Dvallstrom%26start%3D0%26scoring%3Dd%26&_doneTitle=Back+to+Search&&d#6bbce6900ea6d6e4
Daniel Vallstrom |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Jan 10, 2009 12:51 am | All times are GMT
|
|
Free File Hosting | Payday Loans | Credit Card | France Hotels | Mobile Phone
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
C
