|
|
|
|
|
|
| Author |
Message |
CBFalconer
*nix forums Guru
Joined: 09 Mar 2005
Posts: 2502
|
 Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Why pointers can only be subtracted ?
|
|
|
Mike Wahler wrote:
| Quote: | "Eric Sosman" <eric.sosman@sun.com> wrote in message
.... snip ...
Yes, I see that now, but that's just a mistake in the
literal I passed to 'printf'(). The '%lu' argument
passed to printf() was:
(unsigned long)&array[1] - (unsigned long)&array[0])
I.e. each address was converted to an integer, then one
subtracted from the other.
Besides, as Keith Thompson points
out, even the corrected final line demonstrates nothing
about pointer subtraction, because it doesn't subtract
any pointers!
Sure it does. It subtracts the address of array[0]
from the address of array[1].
|
No it doesn't. It subtracts integers, not addresses, because of
the (suspicious) casts, whose effect is already implementation
dependant.
--
"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 |
|
 |
Thomas Stegen
*nix forums beginner
Joined: 25 Feb 2005
Posts: 16
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Why do people call addresses "pointers"?
|
|
|
Mike Wahler wrote:
| Quote: | "Thomas Stegen" <thomas.stegen@gmail.com> wrote in message
news:3694ekF4v64biU1@individual.net...
In the wider sense at least. Null pointer constants might not
be pointers, but there is at least something called null
pointers which are returned by functions. Cause the standard
says so.
'null pointer constant' and 'null pointer' are distinct
concepts.
|
Which is what I allude to above when I say: "Null pointer constants
might not be pointers".
I am not sure I agree to the fact that null pointer constants
are not pointers though.
| Quote: |
Clearly if we have p, which is a variable of type T* and n
which is an int type then p + n is a pointer.
It's an expression which has a pointer type. It's not
an object.
|
That much no one disagrees with.
| Quote: | A pointer is an object.
|
True, but can it also be a value? Look at the description of
malloc for example: It returns a pointer.
"The malloc function returns either a null pointer or a pointer to the
allocated space."
So either the standard is wrong and malloc does not return a pointer,
or you are wrong and expressions can be pointers.
So if you are saying that only objects can be pointers I would like
to see chapter and verse please. Especially in the light of the fact
that object do not have types except when evaluated for their value.
(And then they _may_ be regarded as being of a particular type.)
IOW, talking about an object being and int or a pointer seems informal
in the first place.
Now, I have no problem seeing why some want to say that only objects
can be pointers. I only contend the claim that this is anything other
than an informal colloquioal distinction.
| Quote: |
If you disagree with that then you disagree that the expressions
(n) is an int.
It's not. Expressions are not objects.
|
It's not an object, that much is clear. Only an idiot (or a newbie)
could think that it is. But still, the standard talks about functions
returning ints. So if you want to say that expression cannot evaluate
to int then I want to see chapter and verse.
| Quote: |
Because if you want to make the distinctions between
pointer variables and the values they hold then one should make the
distinction between int variables and the values they hold.
I do.
I see
no reason to treat them differently at least.
There is a distinction between an object and an expression.
|
That's irrelevant here though. The disctinction was between
different types, not object versus expression. (For my very
last statement.)
And the overall discussion is not expression versus object either,
it is whether an expression can be something (in this case a pointer).
--
Thomas. |
|
| 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: eliminating unreferenced parameter warnings
|
|
|
On Tue, 01 Feb 2005 20:46:21 -0800, E. Robert Tisdale wrote:
| Quote: | John Fisher wrote:
void f(int p) {
}
Many (most?) compilers will report that p is unreferenced here.
This may not be a problem as f(int) 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))
|
By defining a macro you can easily change it to whatever is apporpriate to
the compiler you are using. Even if you don't it doesn't make the code
incorrect for other compilers.
| Quote: |
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 would prefer
#define UNUSED(p) ((p) = (p))
although it doesn't matter that much in the context where this should be
used.
| Quote: | 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?
|
If you're worried about this just make a couple of choices available in
the header that defines UNUSED().
| Quote: | You obviously have too much time on your hands.
Warning messages are supposed to be ignored if your code is correct.
|
It would be even better if warning messages didn't exist if your code is
correct. For anybody else who has to maintain your code subsequently
warnings need to be checked. And even for code I wrote I don't want to
have to weed out the genuine errors from the "spurious" warnings each time
I compile something.
| Quote: | Usually, there is an option to silence these warnings
if the verbosity conceals other more important errors and warnings.
|
The point is that the same warning could indicate a genuine error in some
circumstances. Just disabling warnings or classes of warnings is not a
sensible solution to this.
Lawrence |
|
| 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: Division with arrays?
|
|
|
On Tue, 01 Feb 2005 22:12:21 +0000, Keith Thompson wrote:
| Quote: | mjs27@pf.pl (Marcin) writes:
How I can make division of two numbers placed in arrays, example:
short int a[] = {2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2};
short int b[] = {1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2};
short int result[] = a / b; 'division
without additional lib's and header files, only in standart C.
First, define what you mean by division for arrays. The most obvious
meaning result would be an array consisting of the result of dividing
each element in turn (a[0]/b[0], a[1]/b[1], ...), but your arrays are
of different lengths (and the 0's in b would cause problems).
|
The question did state that theree are 2 numbers, so presumable each array
a and b represents a number in some fashion. We don't know how but at a
guess it is probably as a sequence of decimal digits. In which case some
form of decimal long division looks appropriate.
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: eliminating unreferenced parameter warnings
|
|
|
On Wed, 02 Feb 2005 02:11:32 GMT, John Fisher
<fakeid@nospam.com> wrote:
| Quote: | What's your favourite trick and why? Which approach do you think is more
likely to prevent a warning? Has anyone done a survey?
|
#pragma unused x
is the cleanest I've seen. But that is supported even less than the
other methods (x=x; and (void)x unfortunately. Both the redundant
assignment and the cast to void tend to give "statement doesn't do
anything" type errors on various compilers.
Of course, any compiler can give any diagnostics it likes and still be
compliant ("Error 9999: this code is rubbish!") for any or no reason, as
long as it still compiles a valid program...
Chris C |
|
| 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: Division with arrays?
|
|
|
On Tue, 01 Feb 2005 15:52:06 -0800, Kobu wrote:
| Quote: |
Marcin wrote:
How I can make division of two numbers placed in arrays, example:
short int a[] =
{2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2};
short int b[] =
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2};
short int result[] = a / b; 'division
without additional lib's and header files, only in standart C.
You have to manually do this (go through pairs of elements - one in
each array). You're arrays are of different sizes, so your result
array will be the size of the shorter array (and division by zero has
to be handled).
|
1000 / 1 is 1000, i.e. the result is not the size of the "shorter array".
If there are no leading zeros in the numbers it would be
nelems(a)-nelems(b)+1, and if b is larger the result is trivially zero.
| Quote: | example (assuming your declarations for array 'a' and 'b' are done):
.double *result;
.size_t i;
.size_t limit = (sizeof(a)/sizeof(*a) > sizeof(b)/sizeof(*b)) :
sizeof(a)/sizeof(*a) ? sizeof(b)/sizeof(*b);
|
Here you are using the number of elements of the larger of the 2 arrays
which would work but isn't optimal. You might just as well use simply the
number of elements of a, the result of a valid integer division can't be
larger than the dividend.
Lawrence |
|
| 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: utf-8 and ascii
|
|
|
On Tue, 01 Feb 2005 09:46:57 -0800, mail2atulmehta@yahoo.com wrote:
| Quote: | I am genrating a file(.txt file, which is being opened with notepad),
the file has some data from some tables. The tables has fixed column
length, yet When i open in the notepad the column length changes. For
ex the data in one of the column is Republique Française. now the
field length in the table ( FoxPro database) is suppose 75.
|
Your appear to have a problem relating to FoxPro and/or Notepad.
| Quote: | Yet when i
open it in the notepad it becomes 74.
|
So look at the data with some other tool, such as some sort of hex dump
and see whether there is a problem with how the data is being written out
by Foxpro or how Notepad is reading it.
| Quote: | My problem is that when the
encoding changes from ASCII to UTF-8 , the field length ( or the column
length ) for that value also changes.I know it is happening because no
of bits used in ASCII & UTF-8 are different.
|
What encoding, where? Note that pure ASCII text is encoded the same way in
UTF-8. Given the French connection you mention above perhaps the text
isn't pure ASCII.
| Quote: | Is there soem way I can
keep the column length fixed to 75 only,
|
You'll have to ask the Foxpro and/or Notepad experts about that i.e. post
in the appropriate newsgroup.
| Quote: | or is there some programme or code?
|
Maybe, but first you need to determine what is causing the problem. Please
note that comp.lang.c is for discussing the C programming language, not
usage issues of Foxpro and Notepad, or even general UTF-8 character
encoding issues.
Lawrence |
|
| 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: what is the prog coding for this question and what it output
|
|
|
On Wed, 02 Feb 2005 02:37:30 +0000, ozbear wrote:
| Quote: | On Tue, 1 Feb 2005 05:25:16 -0800, "osmium" <r124c4u102@comcast.net
wrote:
snip
I realize that some people use the word "queue" for a linked list, but I
would never do that. To me a queue should connote a physical queue, as a
line of people waiting for a bus. A linked list is something that doesn't
exist in the real world, it's a programmer's invention. OTOH, a queue does
have a real world manifestation.
A series of traffic signposts that you follow to arrive at a final
destination (or any intermediate node/city) is a perfectly good
real world example of a linked list.
|
It is similar but signposts usually tell you about the direction towards
a place, not the location of the next signpost.
Lawrence |
|
| 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: what is the prog coding for this question and what it output
|
|
|
On Tue, 01 Feb 2005 18:24:36 +0000, Chris Croughton wrote:
....
| Quote: | I have often modeled lists and stacks by use of an array. But I consider
those very light duty, not fit for general consumption.
Perhaps yours were. I've seen plenty in embedded real-time systems in
the Real World(tm).
|
Yes, they are viable in well controlled environments.
| Quote: | 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.
Lawrence |
|
| Back to top |
|
|
Mark Piffer
*nix forums beginner
Joined: 19 Apr 2005
Posts: 8
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
Kevin Bracey wrote:
| Quote: | In message <1107186188.438505.282050@f14g2000cwb.googlegroups.com
"Mark Piffer" <sorryonly4spam@yahoo.com> wrote:
Jack Klein wrote:
Admittedly it is unfortunate that the standard does not
specifically
mention bit fields in describing the usual integer conversions,
and
hopefully that can be rectified in a TC or later version.
But since the standard selected what they call "value preserving"
over
"sign preserving" operation, it would be seriously inconsistent
and a
real source of problems if an 8-bit unsigned char promoted to a
signed
int but an 8-bit unsigned bit field promoted to an unsigned int.
That
would be rather absurd, don't you think?
One could claim that it is equally absurd to have a unsigned bit
field
of width 15 promoted to int and one of width 16 to unsigned int
(following value-preservation rules on an example 16-Bit
architecture).
No more absurd than
unsigned char uc;
unsigned short us;
uc + 1 -> int
us + 1 -> unsigned int
is it? Unsigned short promotes to unsigned int only because it is 16
bits
like int. Unsigned char does not. On another, 32-bit, implementation
unsigned
short would promote to int. This "absurdity" already exists for the
main
types.
True, but what I was pointing out is that you have another |
implementation dependent partial order of conversion ranks that you
need to fit (mentally) into the existing one, when with the sign
preservation rule you could have got away very cheap.
| Quote: |
With your argumentation, the type which is used to define the
bitfield
is ignored and the smallest value preserving integer is promoted
to;
this would lead to e.g. signed, unsigned, signed for 15,16,17-width
bitfields, would it not?
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.
To me 6.7.2.1p4 reads as if the width is an implementation defined |
thing, just the use of a bitfield exceeding the width of an int in a
conversion or promotion is left unspecified (I found nothing conclusive
in 6.3). It seems reasonable that at least an assignment is allowed.
OTOH, this makes my previous answer pointless, as any use of an
unsigned bitfield in most expressions is either unproblematic (positive
int -> unsigned int) or not defined at all. (shrug)
Mark |
|
| Back to top |
|
|
CBFalconer
*nix forums Guru
Joined: 09 Mar 2005
Posts: 2502
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: eliminating unreferenced parameter warnings
|
|
|
Randy Howard wrote:
| Quote: | E.Robert.Tisdale@jpl.nasa.gov says...
Some compilers recognize a special comment /*ARGSUSED*/
to prevent this particular warning
but, of course, that's extremely compiler specific.
Don't cobble your code just to appease an inferior compiler.
Your code will be more portable,
if you avoid implementation specific features.
Care to explain how using a comment block as shown above could
impact portability? It may not have the desired result on
every compiler (making the warning go away), but I can't think
of a situation in which it would not compile as a result of
using that comment. Can you?
|
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
|FEED THE TROLLSDALE| :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==============================================================
--
"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 |
|
|
P.J. Plauger
*nix forums Guru
Joined: 16 May 2005
Posts: 365
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: what is size_t
|
|
|
"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote in message
news:ctou7k$mb1$1@newsg1.svr.pol.co.uk...
| Quote: | This is the problem. In my opinion ANSI have dug C into a hole with
size_t.
In a narrow technical sense they are right - malloc() can legitmately be
called with a request for more memory than will fit in INT_MAX, so let's
have a special type. But then that means that strings can be longer than
INT_MAX as well, so strlen() has to return a size_t. Then if strings can
be
longer than INT_MAX, then an index into a character array must be size_t
as
well, And in fact it applies to all objects, so if we represent the number
of employees in a payroll function by an int that is wrong as well,
strictly
it must be size_t. So without really realising they were doing it, ANSI
made
a fundamental change to the language.
|
No, we realized *exactly* what we were doing, and made a fundamental
*cleanup*. That cleanup was more important in the days of 16-bit
addresses than it is now, but it is still a cleanup. Yes, dealing
with unsigned integers can still present problems. And yes, you can
often safely use signed integers when you know the extra unsigned
range is not needed. But unsigned remains a better model than
signed for counting elements of storage, because it's closer to
the actual problem domain.
| Quote: | And this is when more modern language
like Java have done away with unsigned types altogether, because of the
problems they cause.
|
And thus introduce a fresh set of more difficult problems in their
place. I speak as a person who has implemented the Java core library
in Java. Try doing an unsigned divide, remainder, right shift, or
comparison using just signed arithmetic. (And yes, you often need to
do all of the above, in real life.)
Java, BTW, is not really a more "modern" language. It is a *throwback*
to pre-standard C concepts in a number of ways, often to its detriment.
(What new concepts it introduced over C it generally got wrong.)
Evidently, Gosling could never quite wean himself from his first copy
of Kernighan & Ritchie.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com |
|
| 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: calloc/free: a preplexing observation
|
|
|
On Tue, 01 Feb 2005 23:05:16 +0000, Keith Thompson wrote:
| Quote: | "Old Wolf" <oldwolf@inspire.net.nz> writes:
Keith Thompson wrote:
It's pretty clear that lazy allocation is non-conforming.
It's a different sort of non-conformance to something like,
say, giving the wrong result for a division.
I disagree. malloc() is supposed to return a null pointer to indicate
that the requested memory can't be allocated. If it returns a
non-null pointer, it's non-conforming.
|
What we know is that in the *abstract machine* when malloc() returns
non-null an object has been properly created. What an actual
implementation is required to do is a very different and rather more
complex question. Clause 4p6 says
"A conforming hosted implementation shall accept any strictly conforming
program."
"Accept" is the key word here and the standard doesn't define further what
it means. I suggest that it means "not reject" in the sense of saying "I
won't compile this code because it isn't valid C". Consider that a
strictly conforming program can be arbitrarily long and no real-world
compiler is capable of translating every possible strictly conforming
program. The compiler can say "sorry, I can't translate this" in some
fashion, but not "your program is invalid".
5.1.2.3 places requirement on how an implementation must honour the
semantics of the abstract machine. This is based on observable behaviour
notably on I/O and side-effects notably of volatile objects. 5.1.2.3p5
says
"The least requirements on a conforming implementation are:
- At sequence points, volatile objects are stable in the sense that
previous accesses are complete and subsequent accesses have not yet
occurred.
- At program termination, all data written into files shall be identical
to the result that execution of the program according to the abstract
semantics would have produced.
- The input and output dynamics of interactive devices shall
take place as specified in 7.19.3. The intent of these requirements is
that unbuffered or line-buffered output appear as soon as possible, to
ensure that prompting messages actually appear prior to a program
waiting for input."
Note that what is lacking, and what MUST be lacking if there is any chance
of creating a real-world conforming implementation, is any sense that the
implementation must execute the program successfully to completion. All we
know is that IF a sequence point is reached volatile objects are stable,
IF we reach program termination (see 5.1.2.2.3) file output must match the
abstract machine, IF file I/O to interactive devices happens then it
should behave as per the abstract machine.
The standard doesn't guarantee that a conforming implementation will
execute any strictly conforming program to completion (except one
specified in 5.2.4.1), nor does it place any restrictions on how or why
the execution of a program might fail. All that can really be said is that
to the extent that a program does execute it must be consistent with the
abstract machine.
So, aborting the execution of a program, except the one specified by the
implementation w.r.t. 5.2.4.1, because the implementation doesn't
have enough memory available to continue the execution, is very much
allowed by the standard; not in the abstract machine but in an
implementation. 5.2.4.1 is interesting in that an overcommitting system
must make sure that it doesn't trip up for this program. Maybe. Any
multitasking system that doesn't reserve memory permanently for the
possible translation and execution of this program may find itself unable
unable to do so in some circumstances.
Consider:
void foo(void)
{
char data[1000];
puts("I got here");
data[500] = 0;
}
Let's say an implementation aborted the execution of the program at the
statement data[500] = 0; due to hitting a stack quota limit. It spotted
this when the write operation caused a trap on an unmapped memory page and
it tried to allocate a new one. As far as the abstract machine is
concerned the definition of data causes that object to be fully created
when the block is entered, in much the same way that malloc() has created
an object when it returns non-null (for a non-zero argument). So this
is a non-conforming implementation if you consider overcommitting for
malloc'd memory non-conforming.
| Quote: | Would you also say that any operating system that allows
the user to kill an application is non-conforming? (because
it allows the application to abort when the C standard says
it should have kept running).
Programs can always be affected by external interactions (shutting off
the power if nothing else). I suppose it could be argued that
allowing the program not to finish is non-conforming, but I'm not
*quite* that picky.
|
But is the standard? I don't see anything to suggest that at all.
| Quote: | Also, any system where stack overflow is a possibility is
non-conforming (which is pretty much every device with a
stack-based implementation for function calls), unless there
are some limits imposed by the standard which I'm not aware of.
But people have to program on these systems every day.
The standard allows implementations to impose limits.
|
For specific things, none of which are directly relevant here.
| Quote: | No realistic implementation can provide unlimited resources (say, for
infinitely deep recursion or a loop that will take a trillion years to
complete). A realistic implementation can provide a malloc() that
doesn't lie to the client.
|
The question here is conformance. Can a conforming implementation
overcommit or not?
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: eliminating unreferenced parameter warnings
|
|
|
On Wed, 02 Feb 2005 10:07:51 +0000, Lawrence Kirby
<lknews@netactive.co.uk> wrote:
| Quote: | It would be even better if warning messages didn't exist if your code is
correct. For anybody else who has to maintain your code subsequently
warnings need to be checked. And even for code I wrote I don't want to
have to weed out the genuine errors from the "spurious" warnings each time
I compile something.
|
Exactly. Every spurious warning which has to be checked makes it less
likely that real warnings will be noticed (as in the story of the boy
who cried 'wolf'), and slows down maintenance.
| Quote: | Usually, there is an option to silence these warnings
if the verbosity conceals other more important errors and warnings.
The point is that the same warning could indicate a genuine error in some
circumstances. Just disabling warnings or classes of warnings is not a
sensible solution to this.
|
Some compilers allow warnings to be switched on or off (or back to the
default) with a #pragma in the specific part of the code. I think that
is the best solution, because it means that warnings can be disabled
only for sections where they are known to be spurious. Having a #pragma
which says "ignore just this variable if it is unused" is even better in
this case (although not necessarily in the general case).
Chris C |
|
| Back to top |
|
|
Tony Finch
*nix forums Guru
Joined: 22 Mar 2002
Posts: 1222
|
| Posted: Wed Feb 16, 2005 4:51 pm Post subject:
Re: Bit-fields and integral promotion
|
|
|
CBFalconer <cbfalconer@yahoo.com> wrote:
| 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. This is contrary to the usual C practice. The
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?
|
Use an unsigned bit field of course.
| Quote: | 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...
Tony.
--
f.a.n.finch <dot@dotat.at> http://dotat.at/
NORTH FORELAND TO SELSEY BILL: NORTH OR NORTHWEST 4 OR 5, OCCASIONALLY 6 IN
THE EAST. MOSTLY FAIR. MAINLY GOOD. SLIGHT. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Jan 10, 2009 12:27 am | All times are GMT
|
|
Actress | Myspace Layouts | Bankruptcy | PunBB forum hosting | Loans
|
|
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
