Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #25897 > unrolled thread

Limitations and workarounds to expressions defining size of an array

Back to article view | Back to comp.lang.c

Contents

  Limitations and workarounds to expressions defining size of an array Francois Grieu <fgrieu@gmail.com> - 2012-09-04 19:14 +0200
    Re: Limitations and workarounds to expressions defining size of an array James Kuyper <jameskuyper@verizon.net> - 2012-09-04 14:08 -0400
      Re: Limitations and workarounds to expressions defining size of an array Francois Grieu <fgrieu@gmail.com> - 2012-09-05 09:56 +0200
        Re: Limitations and workarounds to expressions defining size of an array James Kuyper <jameskuyper@verizon.net> - 2012-09-05 07:33 -0400
          Re: Limitations and workarounds to expressions defining size of an array Francois Grieu <fgrieu@gmail.com> - 2012-09-05 23:39 +0200
            Re: Limitations and workarounds to expressions defining size of an array Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-05 18:11 -0400
      Re: Limitations and workarounds to expressions defining size of an array James Kuyper <jameskuyper@verizon.net> - 2012-09-05 07:17 -0400
    Re: Limitations and workarounds to expressions defining size of an array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-04 19:18 +0100
    Re: Limitations and workarounds to expressions defining size of an array Kaz Kylheku <kaz@kylheku.com> - 2012-09-04 18:41 +0000
      Re: Limitations and workarounds to expressions defining size of an array "BartC" <bc@freeuk.com> - 2012-09-04 20:22 +0100
        Re: Limitations and workarounds to expressions defining size of an array Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-04 17:07 -0400
          Re: Limitations and workarounds to expressions defining size of an array James Kuyper <jameskuyper@verizon.net> - 2012-09-04 17:25 -0400
            Re: Limitations and workarounds to expressions defining size of an array Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-04 18:24 -0400
              Re: Limitations and workarounds to expressions defining size of an array Keith Thompson <kst-u@mib.org> - 2012-09-04 17:29 -0700
          Re: Limitations and workarounds to expressions defining size of an array army1987 <army1987@ask-for-it.invalid> - 2012-09-04 21:26 +0000
            Re: Limitations and workarounds to expressions defining size of an array army1987 <army1987@ask-for-it.invalid> - 2012-09-04 21:31 +0000
              Re: Limitations and workarounds to expressions defining size of an array James Kuyper <jameskuyper@verizon.net> - 2012-09-04 17:41 -0400
                Re: Limitations and workarounds to expressions defining size of an array army1987 <army1987@ask-for-it.invalid> - 2012-09-05 20:45 +0000
                  Re: Limitations and workarounds to expressions defining size of an array James Kuyper <jameskuyper@verizon.net> - 2012-09-05 17:23 -0400
                    Re: Limitations and workarounds to expressions defining size of an array army1987 <army1987@ask-for-it.invalid> - 2012-09-05 21:30 +0000
                      Re: Limitations and workarounds to expressions defining size of an array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-05 23:04 +0100
                      Re: Limitations and workarounds to expressions defining size of an array Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-05 18:17 -0400
                      Re: Limitations and workarounds to expressions defining size of an array James Kuyper <jameskuyper@verizon.net> - 2012-09-05 18:29 -0400
              Re: Limitations and workarounds to expressions defining size of an array Kaz Kylheku <kaz@kylheku.com> - 2012-09-04 21:44 +0000
        Re: Limitations and workarounds to expressions defining size of an array Kaz Kylheku <kaz@kylheku.com> - 2012-09-04 21:39 +0000
          Re: Limitations and workarounds to expressions defining size of an array "BartC" <bc@freeuk.com> - 2012-09-04 22:58 +0100
            Re: Limitations and workarounds to expressions defining size of an array Kaz Kylheku <kaz@kylheku.com> - 2012-09-04 22:12 +0000
            Re: Limitations and workarounds to expressions defining size of an array Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-09-04 18:55 -0400
        Re: Limitations and workarounds to expressions defining size of an array Keith Thompson <kst-u@mib.org> - 2012-09-04 16:51 -0700
          Re: Limitations and workarounds to expressions defining size of an array Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-04 20:58 -0400
            Re: Limitations and workarounds to expressions defining size of an array Francois Grieu <fgrieu@gmail.com> - 2012-09-05 10:04 +0200
            Re: Limitations and workarounds to expressions defining size of an array Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 04:47 -0700
              Re: Limitations and workarounds to expressions defining size of an array Keith Thompson <kst-u@mib.org> - 2012-09-07 14:04 -0700
                Re: Limitations and workarounds to expressions defining size of an array Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-09-07 16:40 -0500
                Re: Limitations and workarounds to expressions defining size of an array Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 19:54 -0700
                  Re: Limitations and workarounds to expressions defining size of an array Keith Thompson <kst-u@mib.org> - 2012-09-08 14:15 -0700
                    Re: Limitations and workarounds to expressions defining size of an array lawrence.jones@siemens.com - 2012-09-17 12:09 -0400
          Re: Limitations and workarounds to expressions defining size of an array Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 04:53 -0700
            Re: Limitations and workarounds to expressions defining size of an array "BartC" <bc@freeuk.com> - 2012-09-07 13:07 +0100
              Re: Limitations and workarounds to expressions defining size of an array Keith Thompson <kst-u@mib.org> - 2012-09-07 14:08 -0700
              Re: Limitations and workarounds to expressions defining size of an array Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 19:41 -0700
    Re: Limitations and workarounds to expressions defining size of an array "BartC" <bc@freeuk.com> - 2012-09-04 20:26 +0100
    Re: Limitations and workarounds to expressions defining size of an array Barry Schwarz <schwarzb@dqel.com> - 2012-09-04 14:14 -0700
    Re: Limitations and workarounds to expressions defining size of an array Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 04:41 -0700
    Re: Limitations and workarounds to expressions defining size of an array army1987 <army1987@ask-for-it.invalid> - 2012-09-07 13:32 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#25971

army1987 <army1987@ask-for-it.invalid> writes:

> On Wed, 05 Sep 2012 17:23:04 -0400, James Kuyper wrote:
>
>>  In
>> particular, your "WTF?" left me wondering whether you thought the
>> optimization was invalid.
>
> I don't. But 1) I was surprised that strspn() was optimized away, and 2) 
> I seemed to remember seeing a compiler optimizing away printf() some time 
> ago, so I expected that if a compiler would do the former it would do the 
> latter too.

gcc will replace some printf calls that use %s with calls to simpler
functions like puts, but replacing a call that uses a %d format is at
least two steps: convert the constant integer to a string and then
replace the printf call.  I suspect the conversion puts too great a
distance between what's written and the improved result.

An implementation could choose to replace printf calls that is %d with
other functions designed to printf numbers directly, but that would mean
introducing special functions for this relatively rare optimisation.
Had C already had print_int and so on I imagine it might have been
considered (is that hedged enough!?).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25973

On 9/5/2012 5:30 PM, army1987 wrote:
> On Wed, 05 Sep 2012 17:23:04 -0400, James Kuyper wrote:
>
>>   In
>> particular, your "WTF?" left me wondering whether you thought the
>> optimization was invalid.
>
> I don't. But 1) I was surprised that strspn() was optimized away, and 2)
> I seemed to remember seeing a compiler optimizing away printf() some time
> ago, so I expected that if a compiler would do the former it would do the
> latter too.

     Pre-computation of strspn() surprised me, too.  But compilers
have been handling certain special cases of printf() for a long
time.  More than fifteen years ago, a colleague told me of writing
the transformation

	printf("%s\n", ptr);  /* as written */
to
	puts(ptr);  /* as compiled */

... with the usual justification: "One of the SPEC benchmarks used
the printf() a lot, and we got a speed increase by eliminating the
format interpretation."  <Checks> A fairly elderly gcc does this,
even at the default optimization level.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid
"The speed at which the system fails is usually not important."

[toc] | [prev] | [next] | [standalone]

#25974

On 09/05/2012 05:30 PM, army1987 wrote:
> On Wed, 05 Sep 2012 17:23:04 -0400, James Kuyper wrote:
> 
>>  In
>> particular, your "WTF?" left me wondering whether you thought the
>> optimization was invalid.
> 
> I don't. But 1) I was surprised that strspn() was optimized away, and 2) 
> I seemed to remember seeing a compiler optimizing away printf() some time 
> ago, so I expected that if a compiler would do the former it would do the 
> latter too.

What this particular format string causes printf() to do is relatively
simple. The whole thing could have been optimized all the way down to
fputs("3", stdout). However, in general printf() is far more complicated
than strspn(), which might explain why the strspn() call got evaluated
at compile time, while the printf() call did not.

In particular, printf()'s behavior depends upon the current locale,
while strspn()'s  does not. In this simple program, it's easy to confirm
that there's no possibility of setlocale() being called. However, the
need to check for that possibility might have discouraged any attempt to
pre-evaluate the printf() call.

[toc] | [prev] | [next] | [standalone]

#25923

On 2012-09-04, army1987 <army1987@ask-for-it.invalid> wrote:
> On Tue, 04 Sep 2012 21:26:29 +0000, army1987 wrote:
>
>> On Tue, 04 Sep 2012 17:07:39 -0400, Eric Sosman wrote:
>> 
>>>      Don't confuse definition with optimization.  Also, try your
>>> compilers on
>>> 
>>> 	strcspn("BartC", "abcdefghijklmnopqrsBCuvwxyz")
>>> 
>>> ... and let us know if they replace it with `3'.
>> 
>> You meant strspn?
>
> BTW, I'm shocked by the result. It optimizes away the call to strspn but 
> it actually calls printf with arguments "%d\n" and 3? WTF?

Optimizing printf format strings is harder to do than optimizing calls to
strspn.  

To optimize strspn (in the above way), all you have to do is check that the two
arguments are both literal constants, and then call strspn inside the
compiler's execution environment, and substitute the result.

To optimize "%d\n" you have to parse the format string.

People implement whatever is easier. (Which is why we have numerous
concessions all over the C language in the first place.)

[toc] | [prev] | [next] | [standalone]

#25920

On 2012-09-04, BartC <bc@freeuk.com> wrote:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message 
> news:20120904113418.486@kylheku.com...
>> On 2012-09-04, Francois Grieu <fgrieu@gmail.com> wrote:
>>> Can I
>>> - use floating point at all ?
>>> - if yes: use sqrt, log, exp ?
>>
>> No. Constant expressions cannot contain funtion calls.
>
> Yet, an expression such as sqrt(9.0) seems to be reduced to 3.0 on the first 
> two compilers I tried.

That has no bearing on what is constitutes "constant expression".

> It's not much of a stretch to allow that to be used as an array dimension, 
> the main stumbling block being that 3.0 is not integral, while adding an 
> (int) cast makes it look like a runtime expression.

Why does a floating to integer conversion "look" runtime, but a square
root does not?

[toc] | [prev] | [next] | [standalone]

#25924

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20120904143601.389@kylheku.com...
> On 2012-09-04, BartC <bc@freeuk.com> wrote:
>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> news:20120904113418.486@kylheku.com...
>>> On 2012-09-04, Francois Grieu <fgrieu@gmail.com> wrote:
>>>> Can I
>>>> - use floating point at all ?
>>>> - if yes: use sqrt, log, exp ?
>>>
>>> No. Constant expressions cannot contain funtion calls.
>>
>> Yet, an expression such as sqrt(9.0) seems to be reduced to 3.0 on the 
>> first
>> two compilers I tried.
>
> That has no bearing on what is constitutes "constant expression".

The sqrt() call is obviously being evaluated here as the well-known 
mathematical operation rather than an arbitrary C function. (Unless the 
compiler is clever enough to evaluate and reduce the C code inside an actual 
sqrt() function somewhere.)

So the compiler could easily include mathematical functions amongst what are 
considered constant expressions. That it doesn't do so is presumably the 
standard saying it's not allowed (because it's not always practical to do). 
That's unfortunate, because it would be handy.

>> It's not much of a stretch to allow that to be used as an array 
>> dimension,
>> the main stumbling block being that 3.0 is not integral, while adding an
>> (int) cast makes it look like a runtime expression.
>
> Why does a floating to integer conversion "look" runtime, but a square
> root does not?

From the error messages I got ('non-integer expression' with sqrt(), rather 
than 'dynamic expression' with (int)sqrt(), although I can't replicate those 
now..)

-- 
Bartc
 

[toc] | [prev] | [next] | [standalone]

#25926

On 2012-09-04, BartC <bc@freeuk.com> wrote:
>> Why does a floating to integer conversion "look" runtime, but a square
>> root does not?
>
> From the error messages I got ('non-integer expression' with sqrt(), rather 
> than 'dynamic expression' with (int)sqrt(), although I can't replicate those 
> now..)

That's just a consequence of the order in which some checks are applied.

Suppose that some context requires an integral, constant expression.

If you use an expression which is floating-point, and non-constant,
which error message will appear? A complaint that the expression isn't
integral, or that it's non-constant?

If the compiler stops checking an expression after the first constraint
is found, it's going to be whatever is checked first.

[toc] | [prev] | [next] | [standalone]

#25931

"BartC" <bc@freeuk.com> writes:

> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
> news:20120904143601.389@kylheku.com...
>> On 2012-09-04, BartC <bc@freeuk.com> wrote:
>>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>>> news:20120904113418.486@kylheku.com...
>>>> On 2012-09-04, Francois Grieu <fgrieu@gmail.com> wrote:
>>>>> Can I
>>>>> - use floating point at all ?
>>>>> - if yes: use sqrt, log, exp ?
>>>>
>>>> No. Constant expressions cannot contain funtion calls.
>>>
>>> Yet, an expression such as sqrt(9.0) seems to be reduced to 3.0 on
>>> the first
>>> two compilers I tried.
>>
>> That has no bearing on what is constitutes "constant expression".
>
> The sqrt() call is obviously being evaluated here as the well-known
> mathematical operation rather than an arbitrary C function. (Unless
> the compiler is clever enough to evaluate and reduce the C code inside
> an actual sqrt() function somewhere.)

A number of compilers are clever enough to do that, but not necessarily
on a lot of different functions.

> So the compiler could easily include mathematical functions amongst
> what are considered constant expressions. That it doesn't do so is
> presumably the standard saying it's not allowed (because it's not
> always practical to do). That's unfortunate, because it would be
> handy.

Preprocessor manipulations are a fairly rough tool for a number of other
reasons as well. Accordingly, I try to avoid doing anything overly
complicated with them. One alternative is to code the various values and
build a test program to check that they have the correct relationships;
this works more easily when the host platform is also the target
platform, but I've done it in embedded systems also. Another approach is
to generate the values as a separate step before compilation.

>>> It's not much of a stretch to allow that to be used as an array
>>> dimension,
>>> the main stumbling block being that 3.0 is not integral, while adding an
>>> (int) cast makes it look like a runtime expression.
>>
>> Why does a floating to integer conversion "look" runtime, but a square
>> root does not?
>
> From the error messages I got ('non-integer expression' with sqrt(),
> rather than 'dynamic expression' with (int)sqrt(), although I can't
> replicate those now..)

That may not be interesting; if several diagnostics apply, it won't
necessarily give you all of them. The specific messages can depend on
the parsing state at the time it notices an error. It's nice when a
compiler gives you all appropriate messages, but sometimes it's not
practical. 

-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

[toc] | [prev] | [next] | [standalone]

#25934

"BartC" <bc@freeuk.com> writes:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message 
> news:20120904113418.486@kylheku.com...
>> On 2012-09-04, Francois Grieu <fgrieu@gmail.com> wrote:
>>> Can I
>>> - use floating point at all ?
>>> - if yes: use sqrt, log, exp ?
>>
>> No. Constant expressions cannot contain funtion calls.
>
> Yet, an expression such as sqrt(9.0) seems to be reduced to 3.0 on the
> first two compilers I tried.

Yes, I'm sure that's a common optimization.

But the phrase "constant expression" is defined by the standard in
terms of what it can contain; it doesn't merely mean "an expression
that a sufficiently clever compiler can evaluate at compile time".

> It's not much of a stretch to allow that to be used as an array
> dimension, the main stumbling block being that 3.0 is not integral,
> while adding an (int) cast makes it look like a runtime expression.

But where do you draw the line between constant and non-constant
expressions?  The authors of the standard already decided exactly
where to draw that line.  Moving it in the direction of treating
more expressions as constant risks imposing requirements that some
compilers may not be able to meet.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#25937

On 9/4/2012 7:51 PM, Keith Thompson wrote:
> "BartC" <bc@freeuk.com> writes:
>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> news:20120904113418.486@kylheku.com...
>>> On 2012-09-04, Francois Grieu <fgrieu@gmail.com> wrote:
>>>> Can I
>>>> - use floating point at all ?
>>>> - if yes: use sqrt, log, exp ?
>>>
>>> No. Constant expressions cannot contain funtion calls.
>>
>> Yet, an expression such as sqrt(9.0) seems to be reduced to 3.0 on the
>> first two compilers I tried.
>
> Yes, I'm sure that's a common optimization.
>
> But the phrase "constant expression" is defined by the standard in
> terms of what it can contain; it doesn't merely mean "an expression
> that a sufficiently clever compiler can evaluate at compile time".
>
>> It's not much of a stretch to allow that to be used as an array
>> dimension, the main stumbling block being that 3.0 is not integral,
>> while adding an (int) cast makes it look like a runtime expression.
>
> But where do you draw the line between constant and non-constant
> expressions?  The authors of the standard already decided exactly
> where to draw that line.  Moving it in the direction of treating
> more expressions as constant risks imposing requirements that some
> compilers may not be able to meet.

     The Standard draws a line and says "All C compilers accept
everything on this side of the line as constants."  But the line
is permeable: "An implementation may accept other forms of constant
expressions" (6.6p10).  The upshot:

     1) A C compiler must accept `static int x[2+1];', because
        `2+1' is on the hither side of the line,

     2) A C compiler may reject `static int x[strlen("abc")];'
        because `strlen("abc")' is on the thither side, but

     3) A C compiler may accept `static int x[strlen("abc")];'
        under the "other forms" allowance, and need not even
        issue a diagnostic.

     Cases (2) and (3) illustrate why "It works with my compiler"
does not define the language.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid
"The speed at which the system fails is usually not important."

[toc] | [prev] | [next] | [standalone]

#25949

On 05/09/2012 02:58, Eric Sosman wrote:
>     The Standard draws a line and says "All C compilers accept
> everything on this side of the line as constants."  But the line
> is permeable: "An implementation may accept other forms of constant
> expressions" (6.6p10).  The upshot:
>
>     1) A C compiler must accept `static int x[2+1];', because
>        `2+1' is on the hither side of the line,
>
>     2) A C compiler may reject `static int x[strlen("abc")];'
>        because `strlen("abc")' is on the thither side, but
>
>     3) A C compiler may accept `static int x[strlen("abc")];'
>        under the "other forms" allowance, and need not even
>        issue a diagnostic.
>
>     Cases (2) and (3) illustrate why "It works with my compiler"
> does not define the language.

Well said.

Unless I err, we have a portable idiom equivalent to that:

  static int x[sizeof("abc")-1];


  Francois Grieu

[toc] | [prev] | [next] | [standalone]

#26033

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 9/4/2012 7:51 PM, Keith Thompson wrote:
>> "BartC" <bc@freeuk.com> writes:
>>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>>> news:20120904113418.486@kylheku.com...
>>>> On 2012-09-04, Francois Grieu <fgrieu@gmail.com> wrote:
>>>>> Can I
>>>>> - use floating point at all ?
>>>>> - if yes: use sqrt, log, exp ?
>>>>
>>>> No. Constant expressions cannot contain funtion calls.
>>>
>>> Yet, an expression such as sqrt(9.0) seems to be reduced to 3.0 on the
>>> first two compilers I tried.
>>
>> Yes, I'm sure that's a common optimization.
>>
>> But the phrase "constant expression" is defined by the standard in
>> terms of what it can contain; it doesn't merely mean "an expression
>> that a sufficiently clever compiler can evaluate at compile time".
>>
>>> It's not much of a stretch to allow that to be used as an array
>>> dimension, the main stumbling block being that 3.0 is not integral,
>>> while adding an (int) cast makes it look like a runtime expression.
>>
>> But where do you draw the line between constant and non-constant
>> expressions?  The authors of the standard already decided exactly
>> where to draw that line.  Moving it in the direction of treating
>> more expressions as constant risks imposing requirements that some
>> compilers may not be able to meet.
>
>     The Standard draws a line and says "All C compilers accept
> everything on this side of the line as constants."  But the line
> is permeable: "An implementation may accept other forms of constant
> expressions" (6.6p10).  The upshot:
>
>     1) A C compiler must accept `static int x[2+1];', because
>        `2+1' is on the hither side of the line,
>
>     2) A C compiler may reject `static int x[strlen("abc")];'
>        because `strlen("abc")' is on the thither side, but
>
>     3) A C compiler may accept `static int x[strlen("abc")];'
>        under the "other forms" allowance, and need not even
>        issue a diagnostic.
>
>     Cases (2) and (3) illustrate why "It works with my compiler"
> does not define the language.

The principle is right, the specific example is wrong.
Expressions that contain a function call and that must
be constant expressions are constraint violations and
must have a diagnostic issued, regardless of whether
an implementation chooses to regard them as constant
expressions.

[toc] | [prev] | [next] | [standalone]

#26085

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Expressions that contain a function call and that must
> be constant expressions are constraint violations and
> must have a diagnostic issued, regardless of whether
> an implementation chooses to regard them as constant
> expressions.

I'm not convinced that's correct.

N1370 6.6p10 says

    An implementation may accept other forms of constant expressions.

To take one example of a context requiring a constant expression,
6.8.4.2p3 says:

    The expression of each case label shall be an integer constant
    expression and no two of the case constant expressions in the
    same switch statement shall have the same value after conversion.

If an implementation accepts `foo()` as a constant expression, then
using `foo()` in a case label doens't violate that constraint, because
it's a constant expression *for that implementation*.

This is different than the general permission to provide extensions
given by 4p6:

    A conforming implementation may have extensions (including
    additional library functions), provided they do not alter the
    behavior of any strictly conforming program.

which does (I think!) require a diagnostic for any code that would
violate a constraint in the absence of the extension.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#26092

On 2012-09-07 16:04, Keith Thompson wrote:
> This is different than the general permission to provide extensions
> given by 4p6:
>
>      A conforming implementation may have extensions (including
>      additional library functions), provided they do not alter the
>      behavior of any strictly conforming program.
>
> which does (I think!) require a diagnostic for any code that would
> violate a constraint in the absence of the extension.

It's somewhat orthogonal to the issue at hand, but I'm in the mood for 
pointless semantic arguments today. I suggest that "any code that would 
violate a constraint in the absence of the extension" is necessarily NOT 
within the sphere of "any strictly conforming program."

[toc] | [prev] | [next] | [standalone]

#26124

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> Expressions that contain a function call and that must
>> be constant expressions are constraint violations and
>> must have a diagnostic issued, regardless of whether
>> an implementation chooses to regard them as constant
>> expressions.
>
> I'm not convinced that's correct.  [snip elaboration]

This issue was addressed in Defect Report # 261, which reads in
part:

    * If the syntax or context only permits a constant
      expression, the constraints of 6.6#3 and 6.6#4 shall apply.

    * Otherwise [ie, if the constraints above are not violated],
      if the expression meets the requirements of 6.6 (including
      any form accepted in accordance with 6.6#10), it is a
      constant expression.

    * Otherwise it is not a constant expression.

The phrase in []'s is my comment, but I'm confident it's
correct because otherwise the second bullet item makes
no sense.  In any case here is the link if you want to
read the whole thing (be warned!  some of the examples
flow off the right side of the page):

   http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_261.htm

[toc] | [prev] | [next] | [standalone]

#26150

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>> Expressions that contain a function call and that must
>>> be constant expressions are constraint violations and
>>> must have a diagnostic issued, regardless of whether
>>> an implementation chooses to regard them as constant
>>> expressions.
>>
>> I'm not convinced that's correct.  [snip elaboration]
>
> This issue was addressed in Defect Report # 261, which reads in
> part:
>
>     * If the syntax or context only permits a constant
>       expression, the constraints of 6.6#3 and 6.6#4 shall apply.
>
>     * Otherwise [ie, if the constraints above are not violated],
>       if the expression meets the requirements of 6.6 (including
>       any form accepted in accordance with 6.6#10), it is a
>       constant expression.
>
>     * Otherwise it is not a constant expression.
>
> The phrase in []'s is my comment, but I'm confident it's
> correct because otherwise the second bullet item makes
> no sense.  In any case here is the link if you want to
> read the whole thing (be warned!  some of the examples
> flow off the right side of the page):
>
>    http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_261.htm

"In summary, provided the above points are taken account of, the
Committee does not believe the Standard is ambiguous nor that it is
necessary to modify it to make this clearer."

Clive D.W. Feather wasn't entirely sure what the Standard meant, but
it's not necessary to make it any clearer.

Riiiight.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#26472

Keith Thompson <kst-u@mib.org> wrote:
> 
> "In summary, provided the above points are taken account of, the
> Committee does not believe the Standard is ambiguous nor that it is
> necessary to modify it to make this clearer."
> 
> Clive D.W. Feather wasn't entirely sure what the Standard meant, but
> it's not necessary to make it any clearer.
> 
> Riiiight.

To be fair, my friend Clive has a penchant for going out of his way to
not be entirely sure what the Standard means.  It's a trait that's as
valueable as it is annoying, so we always give his input serious
consideration and we end up agreeing with him more often than not. But
not always.
-- 
Larry Jones

What a waste to be going to school on a morning like this. -- Calvin

[toc] | [prev] | [next] | [standalone]

#26034

Keith Thompson <kst-u@mib.org> writes:

> "BartC" <bc@freeuk.com> writes:
>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message 
>> news:20120904113418.486@kylheku.com...
>>> On 2012-09-04, Francois Grieu <fgrieu@gmail.com> wrote:
>>>> Can I
>>>> - use floating point at all ?
>>>> - if yes: use sqrt, log, exp ?
>>>
>>> No. Constant expressions cannot contain funtion calls.
>>
>> Yet, an expression such as sqrt(9.0) seems to be reduced to 3.0 on the
>> first two compilers I tried. [snip]
>
> But where do you draw the line between constant and non-constant
> expressions?  The authors of the standard already decided exactly
> where to draw that line.  [snip]

More specifically, they have drawn two lines, one representing
a minimum set of what are constant expressions, and one
representing which constructs are always out of bounds for
constant expressions -- kind of a lower bound and an upper
bound.  And function calls are over the "not allowed" line.

[toc] | [prev] | [next] | [standalone]

#26038

"Tim Rentsch" <txr@alumni.caltech.edu> wrote in message
news:kfnharam4m1.fsf@x-alumni2.alumni.caltech.edu...
> Keith Thompson <kst-u@mib.org> writes:

>> But where do you draw the line between constant and non-constant
>> expressions?  The authors of the standard already decided exactly
>> where to draw that line.  [snip]
>
> More specifically, they have drawn two lines, one representing
> a minimum set of what are constant expressions, and one
> representing which constructs are always out of bounds for
> constant expressions -- kind of a lower bound and an upper
> bound.  And function calls are over the "not allowed" line.

Perhaps it's about time then that the built-in mathematical functions were
classed as operators, not as arbitrary functions.

Compilers already do that for optimising, but aren't allowed to do that when
the code depends on it (expressions defining array bounds for example,
because it would break on another compiler.)

There are some numeric implications (eg. an array bound could vary slightly
between compilers and machines) but there already are many issues with
floating point anyway. And in examples like the OP's, it wouldn't really 
matter.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#26086

"BartC" <bc@freeuk.com> writes:
> "Tim Rentsch" <txr@alumni.caltech.edu> wrote in message
> news:kfnharam4m1.fsf@x-alumni2.alumni.caltech.edu...
>> Keith Thompson <kst-u@mib.org> writes:
>
>>> But where do you draw the line between constant and non-constant
>>> expressions?  The authors of the standard already decided exactly
>>> where to draw that line.  [snip]
>>
>> More specifically, they have drawn two lines, one representing
>> a minimum set of what are constant expressions, and one
>> representing which constructs are always out of bounds for
>> constant expressions -- kind of a lower bound and an upper
>> bound.  And function calls are over the "not allowed" line.
>
> Perhaps it's about time then that the built-in mathematical functions were
> classed as operators, not as arbitrary functions.
>
> Compilers already do that for optimising, but aren't allowed to do that when
> the code depends on it (expressions defining array bounds for example,
> because it would break on another compiler.)
>
> There are some numeric implications (eg. an array bound could vary slightly
> between compilers and machines) but there already are many issues with
> floating point anyway. And in examples like the OP's, it wouldn't really 
> matter.

Sorry, but I don't think that's a good idea.  Consider, for example, a
cross compiler where the host and target systems have differing
floating-point precision.  (Compilers need to handle this for
floating-point constant, but not for any more complicated expression.)

I think you're understating the problems caused by floating-point
rounding errors.  It could be implementation-defined (or unspecified)
a given switch statement is legal, depending on whether the
expressions in two case labels evaluate to the same integer value.

And how often do you really need to use a floating-point function in a
constant expression?  I don't think it's worth the additional complexity.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web