Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Limitations and workarounds to expressions defining size of an array

Reply
Thread Tools

Limitations and workarounds to expressions defining size of an array

 
 
Casey Carter
Guest
Posts: n/a
 
      09-07-2012
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."

 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      09-08-2012
"BartC" <(E-Mail Removed)> writes:

> "Tim Rentsch" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Keith Thompson <(E-Mail Removed)> 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. [snip elaboration]


Way more trouble than it's worth. If you want to allow
function calls in constant expressions, it's easier
just to move them from the Constraints part of section 6.6
to the Semantics part of the same section.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      09-08-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> 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/wg...ocs/dr_261.htm
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-08-2012
Tim Rentsch <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> Tim Rentsch <(E-Mail Removed)> 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/wg...ocs/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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      09-17-2012
Keith Thompson <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
total array size limitations? glennklockwood C Programming 10 03-16-2009 08:49 AM
service-policy output on a 3560 doesn't work, any workarounds ? hm klette Cisco 2 10-21-2005 09:36 AM
ASP.NET restricts server forms to one per page... workarounds... ??? nzanella@gmail.com ASP .Net 3 01-14-2005 04:54 PM
defining or not defining destructors johny smith C++ 8 07-02-2004 08:51 AM
g++: class size or file size limitations: NONTRIVIAL BUG Neil Zanella C++ 4 10-09-2003 01:49 PM



Advertisments