comp.lang.c - 25 new messages in 6 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Function pointers: performance penalty? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/839dae7a9aa55a30?hl=en
* subroutine stack and C machine model - 12 messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/9246f53562c33dfc?hl=en
* Improving mask-to-bit macro - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/09f4eb1d530ab56b?hl=en
* Adapting software to multiple usage patterns - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/daa37b7bd5a632cf?hl=en
* Floating point to integer casting - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/0ee79c49342126cf?hl=en
* const in C - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/7f7b04d22021c4ad?hl=en

==============================================================================
TOPIC: Function pointers: performance penalty?
http://groups.google.com/group/comp.lang.c/t/839dae7a9aa55a30?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Oct 13 2009 3:17 am
From: Nick Keighley

On 12 Oct, 23:04, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> Keith Thompson <ks...@mib.org> writes:
> > Phil Carmody <thefatphil_demun...@yahoo.co.uk> writes:
> >> Rui Maciel <rui.mac...@gmail.com> writes:

> >>> Is there a performance penalty associated with the use of function
> >>> pointers? If so, how bad is it?
>
> >> Nope, function pointers are faster.
>
> > Could you please expand on this statement?  Was it intended as
> > a joke?  If not, what exactly do you mean?
>
> Was it meaningful?

since I didn't understand it, no

> Was it a direct analogue to the question asked?

dunno what's a "direct analogue"?, so mu

> If you haven't answered "no, yes" in that order, then let's try a
> non-computing analogue:
>
> Subject: Oranges: heavier?
> Are oranges heavy? If so, how much heavier are they?

here's a novel idea, why not just answer the question in plain english
or explain in PE why you think it is a poor question.

To me "is than an overhead to using function pointers" sounds a pretty
ok question. Yes there's all sorts of caveats and implementaion
specific
geegaws. But isn't clc actually here to address questions like that?

--
"That's right!" shouted Vroomfondel "we demand rigidly defined
areas of doubt and uncertainty!"

== 2 of 3 ==
Date: Tues, Oct 13 2009 3:42 am
From: "bartc"

"Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message
news:87skdokvsx.fsf@kilospaz.fatphil.org...
> "bartc" <bartc@freeuk.com> writes:
>> "Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message
>> news:87iqekmfqd.fsf@kilospaz.fatphil.org...
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>>>>> Rui Maciel <rui.maciel@gmail.com> writes:
>>>>>> Is there a performance penalty associated with the use of function
>>>>>> pointers? If so, how bad is it?
>>>>>
>>>>> Nope, function pointers are faster.

> So my apparently meaningless initial answer wasn't there *just* to
> get you to question the question (such as the way an answer of
> nothing more than 'mu' might do, perhaps, or a more direct "what
> would you be doing otherwise?"), but also to encourage you to
> think why I deliberately chose what seemed to be exactly the
> wrong answer if you barge through with all assumptions blazing
> regarding the original question.
>
> For what I use them for, function pointers /are/ faster*.

All very clever. But isn't it you now making assumptions as to the OP's
purpose?

If I'd replied to the OP, which I didn't, I would only have addressed the
obvious question, comparing ordinary function calls with those via explicit
pointers.

And maybe his choice /was/ between those two, we don't know. (Why would he
choose explicit calls if he could do direct calls instead? Well there are a
few cases where that could be considered, although to help make the
decision, it would be useful to know whether explicit pointers incur a
performance penalty...)

--
Bartc

== 3 of 3 ==
Date: Tues, Oct 13 2009 5:12 am
From: Squeamizh

On Oct 12, 1:23 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> "bartc" <ba...@freeuk.com> writes:
> > But oddly I haven't noticed that when I look at asm output.
>
> Maybe you're too busy making ASSumptions.

What is this, the third grade?

==============================================================================
TOPIC: subroutine stack and C machine model
http://groups.google.com/group/comp.lang.c/t/9246f53562c33dfc?hl=en
==============================================================================

== 1 of 12 ==
Date: Tues, Oct 13 2009 3:29 am
From: Chris Dollin

jacob navia wrote:

> Chris Dollin a écrit :
>>
>> So much unlike a contiguous hardware stack that it's a nice counter-
>> example for "C programs need a stack", which is why I was pushing the
>> nitpick.
>>
>> For further amusement, take the static areas for the function variables,
>> and then sort them by variable name or hash of same, so the "stack frames"
>> themselves are discontiguous.
>
> Sure sure.

Yeah, yeah.

> You can imagine what you want.

I already knew that.

> It is worth noting that until
> now a *single* implementation has been documented that implements
> a software stack, for a very marginal processor that lacks a hardware one.

I thought we had at least two relevant examples -- the IBM 360 et seq
(which don't have a "hardware stack") and the ARM (which doesn't have a
hardware-distinguished stack pointer register and for which the C compiler
uses a mixed strategy where stack frames (managed using the conventional
stack pointer & multi-word load-store instrautions) are allocated out
of stack chunks, which in turn are allocated from the C heap.

--
"Is there a reason this is written in iambic pentameter?" Marten,
/Questionable Content/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

== 2 of 12 ==
Date: Tues, Oct 13 2009 4:20 am
From: jacob navia

Chris Dollin a écrit :

> and the ARM (which doesn't have a
> hardware-distinguished stack pointer register and for which the C compiler
> uses a mixed strategy where stack frames (managed using the conventional
> stack pointer & multi-word load-store instrautions) are allocated out
> of stack chunks, which in turn are allocated from the C heap.
>

Sure sure. Please read the ARM architecture description. You are talking
nonsense.

And IBM 360 (maybe you did not know that) stopped being produced
at the beginning of the seventies, last century...

http://www.arm.com/pdfs/ARMv6_Architecture.pdf page 9
That architecture supports even multiple stacks.

But I have had my dose of this. I will not reply to
further remarks of this style.

== 3 of 12 ==
Date: Tues, Oct 13 2009 4:20 am
From: "Dik T. Winter"

In article <Qp6dnThm5-7EuUnXnZ2dnUVZ8iydnZ2d@bt.com> rjh@see.sig.invalid writes:
> In <ooh15vgl4q35.ueitgdn9lkri$.dlg@40tude.net>, Frank wrote:
> > In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:
...
> >> that, those are not two of my favourite functions.
> >
> > Ok. Why are they unfavo(u)red?
...
> > Will you and PJ obligate yourselves one day to get an editor?
>
> I don't know what you mean here.

I think Frank is criticising your use of British spelling. Interesting though
that his sentence would have improved considerably when its advise had been
followed on itself.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

== 4 of 12 ==
Date: Tues, Oct 13 2009 4:59 am
From: Nick Keighley

On 13 Oct, 12:20, jacob navia <ja...@nospam.org> wrote:
> Chris Dollin a écrit :

[machines without dedictaed hardware stacks]

> And IBM 360 (maybe you did not know that) stopped being produced
> at the beginning of the seventies, last century...

with a bit of googling:-

"The zSeries line succeeded the System/390 line (S/390 for short),
maintaining
full backward compatibility. In effect, zSeries machines are the
direct, lineal
descendants of System/360, announced in 1964, and the System/370 from
1970s.
Applications written for these systems can still run, unmodified,
with only
few exceptions, on the newest System z over four decades later."

== 5 of 12 ==
Date: Tues, Oct 13 2009 5:34 am
From: "bartc"

Nick Keighley wrote:
> On 13 Oct, 12:20, jacob navia <ja...@nospam.org> wrote:
>> Chris Dollin a écrit :
>
> [machines without dedictaed hardware stacks]
>
>> And IBM 360 (maybe you did not know that) stopped being produced
>> at the beginning of the seventies, last century...
>
> with a bit of googling:-
>
> "The zSeries line succeeded the System/390 line (S/390 for short),
> maintaining
> full backward compatibility. In effect, zSeries machines are the
> direct, lineal
> descendants of System/360, announced in 1964, and the System/370 from
> 1970s.
> Applications written for these systems can still run, unmodified,
> with only
> few exceptions, on the newest System z over four decades later."

Without actually delving into the details, being backwards compatible
doesn't preclude the newer models from having hardware stacks.

== 6 of 12 ==
Date: Tues, Oct 13 2009 5:55 am
From: Richard Heathfield

In <KrGA5I.8Dw@cwi.nl>, Dik T. Winter wrote:

> In article <Qp6dnThm5-7EuUnXnZ2dnUVZ8iydnZ2d@bt.com>
> rjh@see.sig.invalid writes:
> > In <ooh15vgl4q35.ueitgdn9lkri$.dlg@40tude.net>, Frank wrote:
> > > In Dread Ink, the Grave Hand of Richard Heathfield Did
> > > Inscribe:
> ...
> > >> that, those are not two of my favourite functions.
> > >
> > > Ok. Why are they unfavo(u)red?
> ...
> > > Will you and PJ obligate yourselves one day to get an editor?
> >
> > I don't know what you mean here.
>
> I think Frank is criticising your use of British spelling.

Oh, okay. Thanks for the interpretation. I note that, if "Frank"'s
recent posting history is anything to go by, his criticisms are not
terribly valuable.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 7 of 12 ==
Date: Tues, Oct 13 2009 6:19 am
From: "Dik T. Winter"

In article <hb1noo$t6j$1@aioe.org> jn@nospam.org writes:
> Chris Dollin a écrit :
>
> > and the ARM (which doesn't have a
> > hardware-distinguished stack pointer register and for which the C compiler
> > uses a mixed strategy where stack frames (managed using the conventional
> > stack pointer & multi-word load-store instrautions) are allocated out
> > of stack chunks, which in turn are allocated from the C heap.
> >
>
> Sure sure. Please read the ARM architecture description. You are talking
> nonsense.

What is the hardware-distinguished stack pointer register of the ARM?

> And IBM 360 (maybe you did not know that) stopped being produced
> at the beginning of the seventies, last century...

What about the IBM 370, 390, Z-series?
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

== 8 of 12 ==
Date: Tues, Oct 13 2009 6:30 am
From: "Dik T. Winter"

In article <Jt_Am.2682$KR3.841@text.news.virginmedia.com> "bartc" <bartc@freeuk.com> writes:
...
> > "The zSeries line succeeded the System/390 line (S/390 for short),
> > maintaining
> > full backward compatibility. In effect, zSeries machines are the
> > direct, lineal
> > descendants of System/360, announced in 1964, and the System/370 from
> > 1970s.
> > Applications written for these systems can still run, unmodified,
> > with only
> > few exceptions, on the newest System z over four decades later."
>
> Without actually delving into the details, being backwards compatible
> doesn't preclude the newer models from having hardware stacks.

S/390 certainly had no hardware stack the last time I looked in the
instruction set manual.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

== 9 of 12 ==
Date: Tues, Oct 13 2009 6:53 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

Chris Dollin <chris.dollin@hp.com> writes:
>Nitpick: only if there's some recursion. Otherwise each function can
>have its own static area for storing locals & return addresses.

There is another case, where this will not work:

When there are many functions with a huge size of
automatic storage, but during each run of the program
only one of them is being called.

With memory allocation at run-time only the memory
for the one function called will be allocated, which
might still fit into available memory.

When automatic memory is allocated statically once for
every function, the total amount of memory allocated
might exceed memory limitations.

~~

Otherwise, you always can allocate n copies of the
activation record of a function statically, an then
say that this will work, unless there is recursion
of a depth that is larger than n.

== 10 of 12 ==
Date: Tues, Oct 13 2009 7:03 am
From: Chris Dollin

jacob navia wrote:

> Chris Dollin a écrit :
>
>> and the ARM (which doesn't have a
>> hardware-distinguished stack pointer register and for which the C compiler
>> uses a mixed strategy where stack frames (managed using the conventional
>> stack pointer & multi-word load-store instrautions) are allocated out
>> of stack chunks, which in turn are allocated from the C heap.
>
> Sure sure. Please read the ARM architecture description. You are talking
> nonsense.

I see you're referring to newer ARMs here. I'm afraid I haven't kept up
with the updates to the instruction set; as I remarked in earlier (MUCH
earlier) messages, I'm speaking from my experiences of many years ago.
My bad for not supplying that particular piece of context.

(As far as I can tell, the stack-handling referred to in that document
is for /interupts/, not normal C function calls. Gosh, and it looks
like they've added a bunch of unconditional instructions. Well, they did
say that condition NEV was to be treated with caution ...)

--
"I'm far too ditzy to grasp the subtleties of mockery." Raven,
/Questionable Content/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

== 11 of 12 ==
Date: Tues, Oct 13 2009 7:04 am
From: Chris Dollin

jacob navia wrote:

> And IBM 360 (maybe you did not know that) stopped being produced
> at the beginning of the seventies, last century...

You ignored the "et seq" in my message; the 360 left descendents.

--
"Common concerns such as property damage and wholesale Pintsize
destruction are of no concern to the king!" /Questionable Content/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

== 12 of 12 ==
Date: Tues, Oct 13 2009 7:06 am
From: Chris Dollin

bartc wrote:

> Nick Keighley wrote:
>> On 13 Oct, 12:20, jacob navia <ja...@nospam.org> wrote:
>>> Chris Dollin a écrit :
>>
>> [machines without dedictaed hardware stacks]
>>
>>> And IBM 360 (maybe you did not know that) stopped being produced
>>> at the beginning of the seventies, last century...
>>
>> with a bit of googling:-
>>
>> "The zSeries line succeeded the System/390 line (S/390 for short),
>> maintaining
>> full backward compatibility. In effect, zSeries machines are the
>> direct, lineal
>> descendants of System/360, announced in 1964, and the System/370 from
>> 1970s.
>> Applications written for these systems can still run, unmodified,
>> with only
>> few exceptions, on the newest System z over four decades later."
>
> Without actually delving into the details, being backwards compatible
> doesn't preclude the newer models from having hardware stacks.

While the new models might have acquired stacks, old code running on
them very likely doesn't use them, so they'd continue to be examples
of code that doesn't use hardware stacks.

--
"There is no need to linger." Kildas, /Year of the Unicorn/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

==============================================================================
TOPIC: Improving mask-to-bit macro
http://groups.google.com/group/comp.lang.c/t/09f4eb1d530ab56b?hl=en
==============================================================================

== 1 of 6 ==
Date: Tues, Oct 13 2009 5:06 am
From: James Dow Allen

On Oct 13, 4:47 pm, Francois Grieu <fgr...@gmail.com> wrote:
> #define BIT2MASK(b) (1<<(b))
>
> I need to revert the effect of BIT2MASK, and get back at the bit number
>
> Can we ...
> have a conformant and "pure" macro, which evaluate its
> argument only once ?

I don't about "purity." Two reasons to avoid double evaluation in
#define MASK2BIT(m) ... ??
are
(a) there may be side-effects, e.g. with
MASK2BIT(m *= 2)
(b) execution speed
Start the macro with "(copy_of_m = m, " if (a) is your
concern.

> Or/and can we generate a compile-time error when  m  is
> not a power of two ?

((m) & (m)-1)) is the "not a power of two" condition.

If the compiler knows what m is, (b) above shouldn't be
a concern: MASK2BIT(m) will also be a compile-time constant.

Anyway, a similar question came up a few months ago. Look
for a thread with the subject
((m) /((m)%255+1)/255%255*8 + 7-100/((m)%255+14))
Or just use this subject line as your macro, substituting
(m)+1 for m.

The approach is due to Hallvard B Furuseth, which will
probably be an easier search term to Google than
((m) /((m)%255+1)/255%255*8 + 7-100/((m)%255+14))

James

== 2 of 6 ==
Date: Tues, Oct 13 2009 6:00 am
From: Francois Grieu

James Dow Allen suggested:

> Start the macro with "(copy_of_m = m, "

Many reasons to avoid it:

1) the macro will then be unusable in a preprocessor
expression<ot>, or with inline assembly</ot>.

2) we need to declare copy_of_m.

3) many compilers will become unable to evaluate
the macro at compile time.

4) undefined behavior for MASK2BIT(BIT2MASK(MASK2BIT(8))).

> ((m) & (m)-1)) is the "not a power of two" condition.

Call me picky, but 0 is a relevant exception.

François Grieu

== 3 of 6 ==
Date: Tues, Oct 13 2009 6:30 am
From: spambait@milmac.com (Doug Miller)

In article <4ad479e4$0$421$426a34cc@news.free.fr>, Francois Grieu <fgrieu@gmail.com> wrote:
>James Dow Allen suggested:
>
> > ((m) & (m)-1)) is the "not a power of two" condition.
>
>Call me picky, but 0 is a relevant exception.

How is zero an exception? The expression returns zero whenever m is a power of
two, and non-zero whenever it is not, for all m >= 0:

0 & (-1) = 0
1 & 0 = 0
2 & 1 = 0
3 & 2 = 2
4 & 3 = 0
5 & 4 = 4
6 & 5 = 4
7 & 6 = 6
8 & 7 = 0
etc.

== 4 of 6 ==
Date: Tues, Oct 13 2009 6:40 am
From: Lew Pitcher

On October 13, 2009 09:30, in comp.lang.c, Doug Miller (spambait@milmac.com)
wrote:

> In article <4ad479e4$0$421$426a34cc@news.free.fr>, Francois Grieu
> <fgrieu@gmail.com> wrote:
>>James Dow Allen suggested:
>>
>> > ((m) & (m)-1)) is the "not a power of two" condition.
>>
>>Call me picky, but 0 is a relevant exception.
>
> How is zero an exception? The expression returns zero whenever m is a
> power of two, and non-zero whenever it is not, for all m >= 0:
>
> 0 & (-1) = 0

Can you tell me what power you have to raise two to, to get a result of
zero?

2**0 = 1 nope. 1 != 0
2**1 = 2 nope. 2 != 0

So lets go the other way...

2**-1 = 0.5 nope. 0.5 != 0
2**-2 = 0.25 nope. 0.25 != 0

Hmmmm.... this is looking asymptotic at best.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

== 5 of 6 ==
Date: Tues, Oct 13 2009 6:44 am
From: spambait@milmac.com (Doug Miller)

In article <b788e$4ad48361$cef8a40f$24157@TEKSAVVY.COM>, lew.pitcher@digitalfreehold.ca wrote:
>On October 13, 2009 09:30, in comp.lang.c, Doug Miller (spambait@milmac.com)
>wrote:
>
>> In article <4ad479e4$0$421$426a34cc@news.free.fr>, Francois Grieu
>> <fgrieu@gmail.com> wrote:
>>>James Dow Allen suggested:
>>>
>>> > ((m) & (m)-1)) is the "not a power of two" condition.
>>>
>>>Call me picky, but 0 is a relevant exception.
>>
>> How is zero an exception? The expression returns zero whenever m is a
>> power of two, and non-zero whenever it is not, for all m >= 0:
>>
>> 0 & (-1) = 0
>
>Can you tell me what power you have to raise two to, to get a result of
>zero?
>
>2**0 = 1 nope. 1 != 0
>2**1 = 2 nope. 2 != 0
>
>So lets go the other way...
>
>2**-1 = 0.5 nope. 0.5 != 0
>2**-2 = 0.25 nope. 0.25 != 0
>
>Hmmmm.... this is looking asymptotic at best.
>
Point taken. I haven't had enough coffee this morning, I guess...

== 6 of 6 ==
Date: Tues, Oct 13 2009 7:08 am
From: "Dik T. Winter"

In article <hb1vd8$dtp$1@news.eternal-september.org> spambait@milmac.com (Doug Miller) writes:
> In article <4ad479e4$0$421$426a34cc@news.free.fr>, Francois Grieu <fgrieu@gmail.com> wrote:
> >James Dow Allen suggested:
> >
> > > ((m) & (m)-1)) is the "not a power of two" condition.
> >
> >Call me picky, but 0 is a relevant exception.
>
> How is zero an exception? The expression returns zero whenever m is a power
> of two, and non-zero whenever it is not, for all m >= 0:
>
> 0 & (-1) = 0
> 1 & 0 = 0

In what way is 0 a power of two?
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

==============================================================================
TOPIC: Adapting software to multiple usage patterns
http://groups.google.com/group/comp.lang.c/t/daa37b7bd5a632cf?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 13 2009 5:06 am
From: jacob navia

One of the main arguments being advanced by the people that oppose
the standardization of a container library in C is the fact that
there are many different usage patterns for such a library, and it
would be impossible to satisfy them all.

The solution proposed overcomes this problem in an elegant way
by using a function table.

For example, let's see how that would work in lists, one of the
simplest containers.

As it stands now, the list header structure, with free list, pointer
to first, last, a size_t for the count of the items, and several
other fields could be "top heavy", and bring too much overhead if
the list is very small. For instance, if you know in advance
that you will never store more than 5 items at a time in the
list, such a "top heavy" overhead would be too much.

The solution is to write a specialization of the list
software for very small lists, where (for instance)
you just allocate all the 5 items at once when creating the
list, you eliminate the free list and the heap manager.

You write then, all the functions contained in the interface in a
NEW virtual table (say "small_list.c") and you define a
new virtual table, etc. Then, you just add to the API a
function

newSmallList(size_t element_size);

and you are done. All the code that uses

mylist->lpVtbl->Add(mylist, &data);

will STAY as before identical, without the need to change anything
in it. And one day, when you discover that the list you thought
would be small is no longer small at all, NOTHING must be changed
in the code that uses the list container, only the call to the
normal creation function.

Since all virtual tables are binary compatible (the virtual table
is always the first member) the user code doesn't even need to be
recompiled.

==============================================================================
TOPIC: Floating point to integer casting
http://groups.google.com/group/comp.lang.c/t/0ee79c49342126cf?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Oct 13 2009 5:09 am
From: Tim Rentsch

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> "Morris Keesan" <mkeesan@post.harvard.edu> writes:
[snip]
>> I was going to say that the expression b + c has type (double), but after
>> looking in the standard for confirmation of this, I'm confused:
>>
>> 6.3.1.8 Usual arithmetic conversions
>>
>> "Unless explicitly stated otherwise, the common real type is also
>> the corresponding real type of the result"
>> [so the result of b + c would have type double -- MK]
>
> Agreed.
>
>> but I'm confused by paragraph 2 and its footnote, which say
>>
>> "The values of floating operands and of the results of floating
>> expressions may be represented in greater precision and range
>> than that required by the type; the types are not changed
>> thereby. 52)"
>> and "52) The cast and assignment operators are still required to perform
>> their specified conversions as described in 6.3.1.4 and 6.3.1.5."
>>
>> What's meant by this? If "the types are not changed thereby", does this
>> mean that (b + c) has type double, or not? And if the type is not changed,
>> what conversion would be necessary to do the assignment to a?
>
> It's of type double but may represented by something with greater
> precision than double. Until stuck in an actual double.
>
>> Furthermore, if the result of a floating expression can be "represented
>> in greater precision and range" than that required, what does this say
>> about sizeof(b + c)? What can we predict about the value of the expression
>>
>> sizeof(b + c) == sizeof(double)
>>
>> in conforming implementations? Can a strictly conforming program rely on
>> this having the value 1?
>
> I think the std. requires some clarification on that. The lack of
> distinction between expressions and types leaves the above unclear.
> If the description had stated that all expressions are first treated
> as their type, then you'd be mapped back to double type, and the
> confusion would disappear.

The type of the expression (b+c) is double, as already noted:
"the types are not changed thereby." The sizeof operator works
on types: "The size is determined from the type of the operand."
(6.5.3.4p2). The Standard doesn't leave any wiggle room: the
two types are the same so their sizes are the same; the result
is well-defined and must be equal to 1.

== 2 of 2 ==
Date: Tues, Oct 13 2009 6:42 am
From: "Dik T. Winter"

In article <87bpkbllgo.fsf@kilospaz.fatphil.org> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
...
> I have several archs here where i'd expect to trivially be able to
> come up with values for b, c, e, and f which would yield different
> values for those two expressions. The x86-based ones, if using the
> FPU, because of higher precision intermediates, and the others (POWER,
> Arm) because of fused exact multiply-add instructions. Anything which
> has catastrophic cancellation should work.

Note also that with a fused multiply-add the expression
a * b + c * d == c * d + a * b
is not necessarily true.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

==============================================================================
TOPIC: const in C
http://groups.google.com/group/comp.lang.c/t/7f7b04d22021c4ad?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Oct 13 2009 7:08 am
From: Chander Bhardwaj

Why const in C language is not a compile time constant ?

Regards,
Chander.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en