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

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

malloc and maximum size

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

Contents

  malloc and maximum size "V.Subramanian, India" <subramanian100in@yahoo.com> - 2011-10-14 06:31 -0700
    Re: malloc and maximum size gordonb.pey1d@burditt.org (Gordon Burditt) - 2011-10-14 09:45 -0500
      Re: malloc and maximum size Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-10-14 11:10 -0400
        Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 11:40 -0400
          Re: malloc and maximum size Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-10-14 15:00 -0400
            Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 15:17 -0400
              Re: malloc and maximum size Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-10-14 15:46 -0400
                Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 16:38 -0400
                  Re: malloc and maximum size Ike Naar <ike@iceland.freeshell.org> - 2011-10-14 21:59 +0000
                    Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 18:26 -0400
                  Re: malloc and maximum size Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-10-14 18:42 -0400
                    Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 16:27 -0700
                      Re: malloc and maximum size Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-14 20:41 -0400
                        Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 18:31 -0700
                          Re: malloc and maximum size Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-15 02:58 +0100
                            Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 22:11 -0700
                        Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 22:59 -0400
                          Re: malloc and maximum size Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-14 23:44 -0400
                            Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 22:56 -0700
                            Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-15 07:52 -0400
                            Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:54 -0800
                          Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:51 -0800
                      Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 22:51 -0400
                        Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 22:48 -0700
                          Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-15 07:54 -0400
                            Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-15 11:25 -0700
                              Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-15 21:21 -0400
                                Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 17:41 -0800
                                Re: malloc and maximum size Kaz Kylheku <kaz@kylheku.com> - 2012-01-25 02:11 +0000
                        Re: malloc and maximum size Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-15 11:50 -0400
                          Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-15 21:38 -0400
                            Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 17:33 -0800
                          Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 17:06 -0800
                        Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:58 -0800
                          Re: malloc and maximum size Kaz Kylheku <kaz@kylheku.com> - 2012-01-25 01:23 +0000
                            Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 16:31 -0800
                    Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 22:20 -0400
                  Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 16:03 -0700
                    Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 23:01 -0400
                    Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 17:35 -0800
                      Re: malloc and maximum size Kaz Kylheku <kaz@kylheku.com> - 2012-01-25 02:33 +0000
                        Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 17:14 -0800
                Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:45 -0800
              Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:32 -0800
                Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2012-01-25 02:40 -0800
                  Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 17:27 -0800
            Re: malloc and maximum size Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-14 16:17 -0400
              Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 16:52 -0400
                Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 16:12 -0700
                  Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 23:04 -0400
            Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:36 -0800
      Re: malloc and maximum size Ike Naar <ike@iceland.freeshell.org> - 2011-10-14 16:49 +0000
    Re: malloc and maximum size James Kuyper <jameskuyper@verizon.net> - 2011-10-14 11:05 -0400
    Re: malloc and maximum size Nobody <nobody@nowhere.com> - 2011-10-14 16:11 +0100
    Re: malloc and maximum size Kenneth Brody <kenbrody@spamcop.net> - 2011-10-14 12:24 -0400
    Re: malloc and maximum size jt@toerring.de (Jens Thoms Toerring) - 2011-10-14 17:10 +0000
    Re: malloc and maximum size Stephen Sprunk <stephen@sprunk.org> - 2011-10-14 13:43 -0500
      Re: malloc and maximum size Keith Thompson <kst-u@mib.org> - 2011-10-14 12:03 -0700
        Re: malloc and maximum size jt@toerring.de (Jens Thoms Toerring) - 2011-10-14 20:36 +0000
      Re: malloc and maximum size Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:26 -0800
    Re: malloc and maximum size Seebs <usenet-nospam@seebs.net> - 2011-10-17 17:21 +0000
    Re: malloc and maximum size Shao Miller <sha0.miller@gmail.com> - 2012-01-24 23:49 -0500
      Re: malloc and maximum size Shao Miller <sha0.miller@gmail.com> - 2012-01-24 23:55 -0500

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

#16154

Richard Damon <news.x.richarddamon@xoxy.net> writes:

> On 10/14/11 10:59 PM, James Kuyper wrote:
>> On 10/14/2011 08:41 PM, Richard Damon wrote:
>>> On 10/14/11 7:27 PM, Keith Thompson wrote:
>>>>
>>>> What (arguably) requires the implementation to accept
>>>> "sizeof(char[3500000000])" is the same thing that requires it to
>>>> accept "sizeof(char[10])", namely the sections discussing the sizeof
>>>> operator, the char type, integer constants, and array types.
>>>>
>>>
>>> Why should the compiler be forced to allow the definition of a type that
>>> defines an object bigger than is allowed??
>>
>> No type was defined by that expression.
>>
>>> Note that all valid object sizes must fit within a size_t,
>>
>> More accurately, all sizeof expressions must have a result that fits
>> within a size_t. That's true whether they have a type argument or an
>> expression argument. It's true whether their expression argument is an
>> lvalue or an rvalue. It's true whether or not there's any actual object
>> referred to by the lvalue expression that is their argument.
>>
>> It's also, apparently, true whether or not it's actually possible for
>> the size to be represented by a size_t, because the standard specifies
>> no exemption from that requirement just because it can't be met.  By my
>> standards that constitutes a defect in the standard.
>
> If there exists a type/object whose size can not be expressed by
> sizeof, then the compiler is going to be obligated to generate a
> diagnostic and fail to compile the program.

In fact an implementation isn't obligated to do either of those.
The program could just work.

> If it doesn't, it can't
> meet the requirements of the standard. If it allowed the type/object
> to exist, then it is going to need to rely on the ability to fail for
> exceeding an implementation limit.

I think you're imagining a requirement that the Standard doesn't
actually impose.


> Due to the various problems that arise by having objects bigger than
> can be expressed by size_t, it is better for the compiler to generate
> the diagnostic on attempting to create the enormous type rather than
> wait for the user to apply sizeof to it.

Probably true, but that's a QOI question, not a conformance
question.

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

#16153

James Kuyper <jameskuyper@verizon.net> writes:

> On 10/14/2011 08:41 PM, Richard Damon wrote:
>> On 10/14/11 7:27 PM, Keith Thompson wrote:
>>>
>>> What (arguably) requires the implementation to accept
>>> "sizeof(char[3500000000])" is the same thing that requires it to
>>> accept "sizeof(char[10])", namely the sections discussing the sizeof
>>> operator, the char type, integer constants, and array types.
>>>
>> 
>> Why should the compiler be forced to allow the definition of a type that 
>> defines an object bigger than is allowed??
>
> No type was defined by that expression.
>
>> Note that all valid object sizes must fit within a size_t,
>
> More accurately, all sizeof expressions must have a result that fits
> within a size_t. [snip]

The Standard does not impose such a requirement.

> It's also, apparently, true whether or not it's actually possible for
> the size to be represented by a size_t, because the standard specifies
> no exemption from that requirement just because it can't be met.  By my
> standards that constitutes a defect in the standard.

There's no defect;  it's simply undefined behavior, under 6.5 p5.

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

#11710

On 10/14/2011 07:27 PM, Keith Thompson wrote:
...
> C99 5.2.4.1 discusses translation limits (127 nesting levels of blocks,
> 63 nesting levels of conditional inclusion, etc.).  It requires an
> implementation to accept 65535 bytes in an object, but that doesn't
> apply to the above expression, since it doesn't refer to an object.
> 
> On the other hand, 5.2.4.1 doesn't even say that an implementation
> must always accept 65535 bytes in an object.  It says:
> 
>     The implementation shall be able to translate and execute at least
>     one program that contains at least one instance of every one of the
>     following limits:
> 
> followed by a list of limits.  By rejecting "sizeof(char[3500000000])",
> gcc isn't violating any requirement in 5.2.4.1; presumably it does
> translate and execute that one program (which doesn't include an
> instance of "sizeof(char[3500000000])".
> 
> Presumably an implementation may legitimately reject a program violating
> some limit not listed in 5.2.4.1, such as a trillion-line translation
> unit.  So I *think* that rejecting any program referring to a type
> bigger than 2**31 bytes is permitted.  But I'm not 100% certain.

As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
clauses in the standard. Taking it's words literally, what it fails to
promise renders virtually the entire rest of the standard meaningless;
this is just one example of that fact. Except when I'm arguing against
someone who disagrees on that point, I generally prefer to pretend that
5.2.4.1 says something that allows the rest of the standard to be
meaningful.

In this particular case, I'd prefer to believe that the standard's
requirement that sizeof(type) yield the size of the specified type
(6.5.3.4p2) always applies, except when it's impossible for it to do so,
because the size is too big to be represented by a size_t.
sizeof(char[(size_t)(-1)]) can be represented by a size_t, so it should
not be exempted from that requirement. I will, however, reluctantly
agree that the standard is not clear on that point.
-- 
James Kuyper

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

#11721

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
> clauses in the standard. Taking it's words literally, what it fails to
> promise renders virtually the entire rest of the standard meaningless;
> this is just one example of that fact. Except when I'm arguing against
> someone who disagrees on that point, I generally prefer to pretend that
> 5.2.4.1 says something that allows the rest of the standard to be
> meaningful.
[...]

The problem is that compilers can run out of resources in a plethora
of circumstances, and it's difficult or impossible to define a
coherent set of criteria such that you can reasonably require *all*
programs that meet those criteria are "small" enough that we can
expect all compilers to accept them.

I find 5.2.4.1 a clever way to deal with it.  An implementation
*could* satisfy the rather oddly stated requirement by cheating
(recognizing one specific program that meets all the limits and
does nothing, and treating it as `int main(void) { }").  But in the
absence of that, the easiest way to satisfy 5.2.4.1 is probably to
write a compiler that doesn't impose any fixed limits (as suggested
by the footnote).

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

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

#11729

On 10/15/2011 01:48 AM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
>> clauses in the standard. Taking it's words literally, what it fails to
>> promise renders virtually the entire rest of the standard meaningless;
...
> The problem is that compilers can run out of resources in a plethora
> of circumstances, and it's difficult or impossible to define a
> coherent set of criteria such that you can reasonably require *all*
> programs that meet those criteria are "small" enough that we can
> expect all compilers to accept them.
> 
> I find 5.2.4.1 a clever way to deal with it.  An implementation
> *could* satisfy the rather oddly stated requirement by cheating
> (recognizing one specific program that meets all the limits and
> does nothing, and treating it as `int main(void) { }").  But in the
> absence of that, the easiest way to satisfy 5.2.4.1 is probably to
> write a compiler that doesn't impose any fixed limits (as suggested
> by the footnote).

Oh, I understand the reasons for why it's written that way. That doesn't
mean I have to like it.
-- 
James Kuyper

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

#11735

James Kuyper <jameskuyper@verizon.net> writes:
> On 10/15/2011 01:48 AM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
[...]
>> I find 5.2.4.1 a clever way to deal with it.  An implementation
>> *could* satisfy the rather oddly stated requirement by cheating
>> (recognizing one specific program that meets all the limits and
>> does nothing, and treating it as `int main(void) { }").  But in the
>> absence of that, the easiest way to satisfy 5.2.4.1 is probably to
>> write a compiler that doesn't impose any fixed limits (as suggested
>> by the footnote).
>
> Oh, I understand the reasons for why it's written that way. That doesn't
> mean I have to like it.

Do you have ideas for improving it?

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

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

#11748

On 10/15/2011 02:25 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 10/15/2011 01:48 AM, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>>> I find 5.2.4.1 a clever way to deal with it.  An implementation
>>> *could* satisfy the rather oddly stated requirement by cheating
>>> (recognizing one specific program that meets all the limits and
>>> does nothing, and treating it as `int main(void) { }").  But in the
>>> absence of that, the easiest way to satisfy 5.2.4.1 is probably to
>>> write a compiler that doesn't impose any fixed limits (as suggested
>>> by the footnote).
>>
>> Oh, I understand the reasons for why it's written that way. That doesn't
>> mean I have to like it.
> 
> Do you have ideas for improving it?

1. Require that any that any program that contains no syntax errors,
constraint violations, or undefined behavior, and which does not exceed
any of those limits, must be translated and, when executed, must produce
a) the behavior defined by the standard for that program, insofar as it
is defined by the standard
b) the behavior defined by the implementation's documentations, insofar
as the behavior is implementation-define
c) behavior that is with permitted range of possibilities, insofar as it
is unspecified.

2. Expand the list of implementation limits to include every feature a
program might possess that might make it difficult to satisfy that
requirement.

3. Lower the values of the implementation limits enough (but no more
than necessary) to make it acceptably easy to create an implementation
satisfying that requirement.

I can't fill in the details on items 2 and 3, that would have to be done
by people who are experts in compiler design, about which I know little.
 When I've previously discussed ideas along this line, I've been told that
a) the list of implementation limits called for by item 2 would have to
be infinitely long.

b) to achieve item 3 the limits would have to be so low that EVERY
useful program would exceed at least one limit.

I doubt that those assertions are true, but I'm not enough of an expert
to be sure. a) is a serious flaw, if true. b) merely means that the best
we can do is not very good; it would still be better than the current
situation.
-- 
James Kuyper

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

#16162

James Kuyper <jameskuyper@verizon.net> writes:

> On 10/15/2011 02:25 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> On 10/15/2011 01:48 AM, Keith Thompson wrote:
>>>> James Kuyper <jameskuyper@verizon.net> writes:
>> [...]
>>>> I find 5.2.4.1 a clever way to deal with it.  An implementation
>>>> *could* satisfy the rather oddly stated requirement by cheating
>>>> (recognizing one specific program that meets all the limits and
>>>> does nothing, and treating it as `int main(void) { }").  But in the
>>>> absence of that, the easiest way to satisfy 5.2.4.1 is probably to
>>>> write a compiler that doesn't impose any fixed limits (as suggested
>>>> by the footnote).
>>>
>>> Oh, I understand the reasons for why it's written that way. That doesn't
>>> mean I have to like it.
>> 
>> Do you have ideas for improving it?
>
> 1. Require that any that any program that contains no syntax errors,
> constraint violations, or undefined behavior, and which does not exceed
> any of those limits, must be translated and, when executed, must produce
> a) the behavior defined by the standard for that program, insofar as it
> is defined by the standard
> b) the behavior defined by the implementation's documentations, insofar
> as the behavior is implementation-define
> c) behavior that is with permitted range of possibilities, insofar as it
> is unspecified.
>
> 2. Expand the list of implementation limits to include every feature a
> program might possess that might make it difficult to satisfy that
> requirement.
>
> 3. Lower the values of the implementation limits enough (but no more
> than necessary) to make it acceptably easy to create an implementation
> satisfying that requirement.  [snip incidental]

Interesting idea, but quite impractical.

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

#16166

On 2011-10-16, James Kuyper <jameskuyper@verizon.net> wrote:
>> Do you have ideas for improving it?
>
> 1. Require that any that any program that contains no syntax errors,
> constraint violations, or undefined behavior, and which does not exceed
> any of those limits, must be translated and, when executed, must produce

This appears superfluous, because this notion of conformance follows from
all the other requirements.  What you've written adds up to "an implementation
shall be conforming" (i.e. there exists no valid test case or other proof
method that finds it nonconforming.)

It already follows from the rest of the document.  Whenever you take a
program that is within the limits, you can use the standard to deduce what that
program's behavior should be (if that program is also portable and has a
well-defined behavior). If you don't get that behavior, then you have hit upon
a test case indicating nonconformity (and you know that with or without
the proposed paragraph).

Moreover, the proposed paragraph troublingly suggests that the implementors
must validate their work by an astonishingly vast set of test cases (that will
fill more than the world's total hard drive storage, and yet which fails to
represent real-world situations) or failing that, prove it correct with
formal methods.

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

#11731

On 10/14/11 10:51 PM, James Kuyper wrote:
> On 10/14/2011 07:27 PM, Keith Thompson wrote:
> ...
>> C99 5.2.4.1 discusses translation limits (127 nesting levels of blocks,
>> 63 nesting levels of conditional inclusion, etc.).  It requires an
>> implementation to accept 65535 bytes in an object, but that doesn't
>> apply to the above expression, since it doesn't refer to an object.
>>
>> On the other hand, 5.2.4.1 doesn't even say that an implementation
>> must always accept 65535 bytes in an object.  It says:
>>
>>      The implementation shall be able to translate and execute at least
>>      one program that contains at least one instance of every one of the
>>      following limits:
>>
>> followed by a list of limits.  By rejecting "sizeof(char[3500000000])",
>> gcc isn't violating any requirement in 5.2.4.1; presumably it does
>> translate and execute that one program (which doesn't include an
>> instance of "sizeof(char[3500000000])".
>>
>> Presumably an implementation may legitimately reject a program violating
>> some limit not listed in 5.2.4.1, such as a trillion-line translation
>> unit.  So I *think* that rejecting any program referring to a type
>> bigger than 2**31 bytes is permitted.  But I'm not 100% certain.
>
> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
> clauses in the standard. Taking it's words literally, what it fails to
> promise renders virtually the entire rest of the standard meaningless;
> this is just one example of that fact. Except when I'm arguing against
> someone who disagrees on that point, I generally prefer to pretend that
> 5.2.4.1 says something that allows the rest of the standard to be
> meaningful.
>

One interesting thing to note, is that in reading 5.2.4.1, the standard 
does NOT give the implementation any right to fail to translate a 
program that exceeds the limits. It can NOT be claimed to be undefined 
or unspecified behavior, as the standard's definition of conformance is 
NOT limited to these limits (the only restriction I find is that a 
strictly conforming program can not violate those limits). The standard 
requires that the compiler must be able to succeed on one given program, 
but grants no permission to fail.

I suppose that this is really a defect in the standard, and the standard 
needs some language to allow the implementation to establish limits, and 
to generate a diagnostic and reject a program that exceeds these limits.

Exceeding implementation limits must NOT be considered undefined 
behavior, (unless the definition of implementation limits is vastly 
improved) as currently you can not know if a given program exceeds the 
implementation limits, so considering it undefined behavior, and not 
requiring a diagnostic, means it is impossible to show any given 
implementation as "non-conforming", as any non-conforming behavior can 
be blamed on exceeding some implementation limit.

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

#11751

On 10/15/2011 11:50 AM, Richard Damon wrote:
> On 10/14/11 10:51 PM, James Kuyper wrote:
...
>> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
>> clauses in the standard. Taking it's words literally, what it fails to
>> promise renders virtually the entire rest of the standard meaningless;
>> this is just one example of that fact. Except when I'm arguing against
>> someone who disagrees on that point, I generally prefer to pretend that
>> 5.2.4.1 says something that allows the rest of the standard to be
>> meaningful.
>>
> 
> One interesting thing to note, is that in reading 5.2.4.1, the standard 
> does NOT give the implementation any right to fail to translate a 
> program that exceeds the limits.

The standard requires acceptance of strictly conforming programs;
without defining what "accept" means. In ordinary English, I can accept
a gift without even opening it; and I can discard it after it accepting
it. Whether or not something else was actually intended, the failure to
provide any alternative to the common English defining of "accept"
renders that requirement toothless.

Note that, in any event, a program which exceeds the minimum
implementation limits in 5.2.4.1 is not strictly conforming.

5.2.4.1 is the ONLY clause that mandates that a conforming
implementation of C be able to translate and execute any program; and
that requirement only applies to the "one program"; which is pretty
unlikely to be any program I ever care to execute. YMMV :-)

> ... It can NOT be claimed to be undefined
> or unspecified behavior, as the standard's definition of conformance is 
> NOT limited to these limits (the only restriction I find is that a 
> strictly conforming program can not violate those limits). The standard 
> requires that the compiler must be able to succeed on one given program, 
> but grants no permission to fail.

It also imposes no requirement that it succeed, with one worthless
exception.

> I suppose that this is really a defect in the standard, and the standard 
> needs some language to allow the implementation to establish limits, and 
> to generate a diagnostic and reject a program that exceeds these limits.
> 
> Exceeding implementation limits must NOT be considered undefined 
> behavior, (unless the definition of implementation limits is vastly 
> improved) as currently you can not know if a given program exceeds the 
> implementation limits, so considering it undefined behavior, and not 
> requiring a diagnostic, means it is impossible to show any given 
> implementation as "non-conforming", as any non-conforming behavior can 
> be blamed on exceeding some implementation limit.

While I agree that that exceeding an implementation limit does not
render the behavior undefined, it does cancel the ONLY requirement that
an implementation even "accept" the program, much less translate and
execute it.

Oddly enough, the one program that an implementation is required to be
able to translate and execute is one that happens to be permitted to
exceed the minimum implementation limits.
-- 
James Kuyper

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

#16160

James Kuyper <jameskuyper@verizon.net> writes:

> [snip]
>
> Oddly enough, the one program that an implementation is required to be
> able to translate and execute is one that happens to be permitted to
> exceed the minimum implementation limits.

Silly.  Programs don't need "permission" to exceed minimum
implementation limits.  Whether an implemetation accepts such
programs or not is up to it, either for its distinguished
program or any other one.

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

#16157

Richard Damon <news.x.richarddamon@xoxy.net> writes:

> On 10/14/11 10:51 PM, James Kuyper wrote:
>> On 10/14/2011 07:27 PM, Keith Thompson wrote:
>> ...
>>> C99 5.2.4.1 discusses translation limits (127 nesting levels of blocks,
>>> 63 nesting levels of conditional inclusion, etc.).  It requires an
>>> implementation to accept 65535 bytes in an object, but that doesn't
>>> apply to the above expression, since it doesn't refer to an object.
>>>
>>> On the other hand, 5.2.4.1 doesn't even say that an implementation
>>> must always accept 65535 bytes in an object.  It says:
>>>
>>>      The implementation shall be able to translate and execute at least
>>>      one program that contains at least one instance of every one of the
>>>      following limits:
>>>
>>> followed by a list of limits.  By rejecting "sizeof(char[3500000000])",
>>> gcc isn't violating any requirement in 5.2.4.1; presumably it does
>>> translate and execute that one program (which doesn't include an
>>> instance of "sizeof(char[3500000000])".
>>>
>>> Presumably an implementation may legitimately reject a program violating
>>> some limit not listed in 5.2.4.1, such as a trillion-line translation
>>> unit.  So I *think* that rejecting any program referring to a type
>>> bigger than 2**31 bytes is permitted.  But I'm not 100% certain.
>>
>> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
>> clauses in the standard. Taking it's words literally, what it fails to
>> promise renders virtually the entire rest of the standard meaningless;
>> this is just one example of that fact. Except when I'm arguing against
>> someone who disagrees on that point, I generally prefer to pretend that
>> 5.2.4.1 says something that allows the rest of the standard to be
>> meaningful.
>>
>
> One interesting thing to note, is that in reading 5.2.4.1, the
> standard does NOT give the implementation any right to fail to
> translate a program that exceeds the limits. It can NOT be claimed to
> be undefined or unspecified behavior, as the standard's definition of
> conformance is NOT limited to these limits (the only restriction I
> find is that a strictly conforming program can not violate those
> limits). The standard requires that the compiler must be able to
> succeed on one given program, but grants no permission to fail.
> [snip elaboration]

All that matters is that the Standard doesn't impose any requirement
to _accept_ an arbitrary program, except strictly conforming ones.
In the absence of any stated requirement on this axis, an
implementation is free to do as it chooses and still be
conforming.

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

#16155

James Kuyper <jameskuyper@verizon.net> writes:

> On 10/14/2011 07:27 PM, Keith Thompson wrote:
> ...
>> C99 5.2.4.1 discusses translation limits (127 nesting levels of blocks,
>> 63 nesting levels of conditional inclusion, etc.).  It requires an
>> implementation to accept 65535 bytes in an object, but that doesn't
>> apply to the above expression, since it doesn't refer to an object.
>> 
>> On the other hand, 5.2.4.1 doesn't even say that an implementation
>> must always accept 65535 bytes in an object.  It says:
>> 
>>     The implementation shall be able to translate and execute at least
>>     one program that contains at least one instance of every one of the
>>     following limits:
>> 
>> followed by a list of limits.  By rejecting "sizeof(char[3500000000])",
>> gcc isn't violating any requirement in 5.2.4.1; presumably it does
>> translate and execute that one program (which doesn't include an
>> instance of "sizeof(char[3500000000])".
>> 
>> Presumably an implementation may legitimately reject a program violating
>> some limit not listed in 5.2.4.1, such as a trillion-line translation
>> unit.  So I *think* that rejecting any program referring to a type
>> bigger than 2**31 bytes is permitted.  But I'm not 100% certain.
>
> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
> clauses in the standard. Taking it's words literally, what it fails to
> promise renders virtually the entire rest of the standard meaningless;
> [snip]

I'm sure that's true for some, but most people who read
the Standard have no real problem with it.  Show of hands,
anyone?

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

#16158

On 2012-01-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
>> clauses in the standard. Taking it's words literally, what it fails to
>> promise renders virtually the entire rest of the standard meaningless;
>> [snip]
>
> I'm sure that's true for some, but most people who read
> the Standard have no real problem with it.  Show of hands,
> anyone?

5.2.4.1 simply gives a set of requirements in such a way that it is clear
that all of the limits are independent. An implementation should be able to
translate a program which exercises each of the limits /simultaneously/.
That is the point. The implementation canot assert that, oops, since you
declared an object of 65535 bytes, you can only have 63 nesting of blocks, and
not the required 127.

At the same time, it is not right to require an implementation to be able to
handle EVERY program which contains an instance of each of the limits.  That
category includes arbitrarily large programs. Moreover, it is not a testable
requirement because the set of programs is infinite.

Should the requirement say "three programs"? Fifty? One program is enough to
show that the limits can be hit concurrently.

There is clearly no intent there that conformance is hinged to a single test
case which exercises some limits. Such a program does not have anywhere near
the required coverage anyway to properly test a compiler. Nowhere is it
stated that if the implementation translates at least one such a program, it is
blessed as conforming and the job is done. "shall" does not mean "shall only".

The standard does not provide any acceptance test suite (and that does not
make it meaningless either).  It is meant to be used as a kind of "contract"
between implementors and users. It's clear to everyone involved that there are
numerous detailed requirements given in the standard, and that users want to
see the requirements implemented earnestly so that a wide range of programs can
be translated and not just a few hand-picked ones.  It's up to the parties to
decide what constitutes an acceptance test.  There often isn't one. If the
compiler isn't freeware, you may have some customer support, and failing that,
a "money back" type warranty where liability is limited to a refund of the
purchase price.

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

#16538

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2012-01-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> As I'm sure you're already aware, 5.2.4.1 is one of my least favorite
>>> clauses in the standard. Taking it's words literally, what it fails to
>>> promise renders virtually the entire rest of the standard meaningless;
>>> [snip]
>>
>> I'm sure that's true for some, but most people who read
>> the Standard have no real problem with it.  Show of hands,
>> anyone?
>
> 5.2.4.1 simply gives a set of requirements in such a way that it is clear
> that all of the limits are independent. An implementation should be able to
> translate a program which exercises each of the limits /simultaneously/.
> That is the point. The implementation canot assert that, oops, since you
> declared an object of 65535 bytes, you can only have 63 nesting of blocks, and
> not the required 127.  [snip some elaboration of that]
>
> There is clearly no intent there that conformance is hinged to a single test
> case which exercises some limits.  [snip]

5.2.4.1 simply establishes a lower bound, and in my opinion a
fairly reasonable one.  Everything above the 5.2.4.1 lower bound
is therefore relegated to QOI, which I think makes a lot of
sense, and certainly more sense than going to the other extreme.
The purpose of the Standard is to define the language (albeit
indirectly, by giving requirements for implementations of the
language);  it is not to establish what constitutes a minimally
"acceptable" implementation, which is better left to some other
arena.

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

#11709

On 10/14/2011 06:42 PM, Lowell Gilbert wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> On 10/14/2011 03:46 PM, Lowell Gilbert wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>
>>>> On 10/14/2011 03:00 PM, Lowell Gilbert wrote:
...
>>>>> For size_t, the type is just defined as the output type for sizeof,
>>>>> which is defined in turn as yielding the size of its operand.  So I can
>>>>> see an argument that the "maximum value" of a size_t could be viewed as
>>>>> the largest value that sizeof could possibly yield on the particular
>>>>> implementation.

I realize now that I passed over the paragraph above without commenting
on it. I disagree with it's assertions. sizeof expressions have a type,
and size_t is a typedef for that type, but that's the definition of the
typedef, not the definition of the type. That type can be, and usually
is, a type that already can be named in some other manner by the user,
such as "unsigned long". It's defined in terms of it's properties, not
by the fact that one of the things it's used for is as the result type
of sizeof expressions. It must be suitable for such use, or the typedef
is inappropriate, but it's maximum value is a property of the type
itself, not a property of one particular use of that type.

>>>> Well, the maximum value returnable by sizeof has to be the same as the
>>>> maximum value representable by size_t:
>>>>
>>>> 	sizeof(char[(size_t)-1]) == (size_t)(-1)
>>>
>>> Assuming I understand what you're getting at, you're begging the
>>> question here.  [But the expression doesn't make sense to me, so 
>>> the assumption may well be wrong.]
>>
>> I had not intended to beg the question. Per 6.3.1.3p2, (size_t)(-1) is
>> precisely "the maximum value that can be represented" as a size_t.
> 
> Then you were indeed begging the question; the equality is *exactly*
> what I'm questioning.

I don't see how "begging the question" comes into play. I thought the
truth of that equality was perfectly clear, and did not present a
detailed argument for it until after I realized that you disagreed.
However, in that argument, I did not assume that equality to be true, I
generated that conclusion from various more fundamental features of C.

>> char[(size_t)(-1)] is an array type whose size in bytes is (size_t)(-1).
>> sizeof(char[(size_t)(-1)]) must therefore yield a value which is
>> (size_t)(-1). Therefore, the largest value that sizeof could possibly
>> yield must be (size_t)(-1), the same as the maximum representable value.
> 
> I see; I was assuming you were giving a C expression, since it looked
> like one.  Thanks for the explanation.

Yes, your assumption was correct, sizeof(char[(size_t)(-1)]) is indeed a
C expression.

Keith has already addressed your other points, though not exactly in the
fashion that I would have. It will simplify things if I respond to his
message, rather than yours.
-- 
James Kuyper

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

#11700

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> Not even sizeof(char[3500000000])? For an implementation where
> (size_t)(-1) is 4294967295, what gives that implementation permission to
> do anything with that expression other than yield a value of
> (size_t)3500000000? The implementation is free to issue a diagnostic, of
> course, but not to reject the code.

Interesting.  For the following program:

#include <stdio.h>
int main(void) {
    printf("%zu\n", sizeof (char[(size_t)-1]));
    return 0;
}

"gcc -std=c99" rejects it with an error message:

c.c: In function ‘main’:
c.c:3:5: error: size of unnamed array is too large

Change the array size to (size_t)-1/2 and it compiles and prints
"2147483647".  Change it to (size_t)-1/2+1 and it rejects it with the
same error message.

Does this make "gcc -std=c99" non-conforming?

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

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

#11712

On 10/14/2011 07:03 PM, Keith Thompson wrote:
...
> Interesting.  For the following program:
> 
> #include <stdio.h>
> int main(void) {
>     printf("%zu\n", sizeof (char[(size_t)-1]));
>     return 0;
> }
> 
> "gcc -std=c99" rejects it with an error message:
> 
> c.c: In function ‘main’:
> c.c:3:5: error: size of unnamed array is too large
> 
> Change the array size to (size_t)-1/2 and it compiles and prints
> "2147483647".  Change it to (size_t)-1/2+1 and it rejects it with the
> same error message.
> 
> Does this make "gcc -std=c99" non-conforming?

I've argued that such behavior would make it non-conforming, but the
implementation-limits issue is sufficiently foggy that it's not at all
clear.
-- 
James Kuyper

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

#16161

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

> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> Not even sizeof(char[3500000000])? For an implementation where
>> (size_t)(-1) is 4294967295, what gives that implementation permission to
>> do anything with that expression other than yield a value of
>> (size_t)3500000000? The implementation is free to issue a diagnostic, of
>> course, but not to reject the code.
>
> Interesting.  For the following program:
>
> #include <stdio.h>
> int main(void) {
>     printf("%zu\n", sizeof (char[(size_t)-1]));
>     return 0;
> }
>
> "gcc -std=c99" rejects it with an error message:
>
> c.c: In function 'main':
> c.c:3:5: error: size of unnamed array is too large
>
> Change the array size to (size_t)-1/2 and it compiles and prints
> "2147483647".  Change it to (size_t)-1/2+1 and it rejects it with the
> same error message.
>
> Does this make "gcc -std=c99" non-conforming?

No, because there is no requirement that this program
be accepted.

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

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

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

csiph-web