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

Groups > comp.lang.c > #20956

Re: Removing an element from Queue

Show all headers | View raw

On 05/17/2012 06:21 PM, Barry Schwarz wrote:
> On Thu, 17 May 2012 15:38:58 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
> 
>> [Note: corrected typo in Subject: header]
>>
>> On 05/17/2012 02:48 PM, Barry Schwarz wrote:
>>> On Thu, 17 May 2012 09:09:12 -0400, James Kuyper
>>> <jameskuyper@verizon.net> wrote:
>>>
>>>> On 05/16/2012 07:30 PM, Barry Schwarz wrote:
>>>>> On Wed, 16 May 2012 07:18:35 -0400, James Kuyper
>>>>> <jameskuyper@verizon.net> wrote:
>>>>>
>>>>>> On 05/15/2012 11:38 PM, Barry Schwarz wrote:
>>>>>>> On Tue, 15 May 2012 23:03:39 -0400, James Kuyper
>>>>>>> <jameskuyper@verizon.net> wrote:
>>>>>> ...
>>>>>>>> calloc(a,b) must either return a pointer to enough memory to store 'a'
>>>>>>>> objects, each of size 'b' bytes, or a null pointer. If the mathematical
>>>>>>>> product of a*b is greater than SIZE_MAX, then (size_t)(a*b) bytes will
>>>>>>>> not be sufficient to meet that requirement - but the requirement still
>>>>>>>> holds. Therefore, calloc(a,b) must either return a null pointer, or
>>>>>>>> allocate sufficient memory by some mechanism other than malloc(a*b).
>>>>>>
>>>>>> ...
>>>>>>> array.  size_t must be able to hold the size in bytes of the largest
>>>>>>> possible object, including aggregates such as arrays.
>>>>>>
>>>>>> Citation, please?
>>>>>
>>>>> K&R II, page 135, a stand-alone unindented paragraph approximately 1/3
>>>>> of the way down the page: "C provides a compile-time unary operator
>>>>> called sizeof that can be used to compute the size of any object."
>>>>>
>>>>
>>>> K&R II is not authoritative. The C standard is. K&R II often says things
>>>> less precisely than the standard. 
>> ...
>>>> Also note that the words you cite from K&R II are not, in themselves,
>>>> sufficient to support your position. "can be used to compute" doesn't
>>>> require that the computation be carried out using size_t. If it were in
>>>
>>> Regardless of how the computation is carried out, the result must fit
>>> in a size_t.
>>
>> Citation, please?
> 
> Unless I misread your original response, which has been snipped beyond
> recognition above, the result in question was the evaluation of the
> sizeof operator. ...

No, the result in question was the calculation of "... the size of any
object." The text saying so was yours, not mine, and it has survived all
snipping.

> ...  Is there some debate about the type of  this
> evaluation?

No, there's a debate about whether that type is required to be capable
of holding "the size of any object". I contend it's only required to
hold the size of types, whether or not there's an object of that type.
Passing a type to sizeof, either directly or through an expression of
that type, whose size cannot be represented in size_t, renders the
behavior undefined by reason of a lack of definition (or more precisely,
by reason of an internally contradictory definition of the behavior).

>>> My only assertion was that since the result of calloc(a,b) is to be
>>> treated as a single array, calloc should fail if a*b mathematically
>>> exceeds SIZE_MAX.
>>
>> An assertion for which you've provided no citations from the standard,
>> nor any arguments based upon such citations. Even the citation you have
>> provided from K&R II fails to specify any such requirement.
> 
> I'll agree to disagree.

I'd prefer an explanation of your disagreement, over a bald statement of it.

>>> The wording is unchanged in n1570.
>>
>> The wording of what? All of the citations from the standard so far have
>> been made by me, and none of them are worded in such a way as to
>> conflict with the implementation I described.
> 
> So my quote from 7.20.3.1 wasn't from the standard?

Sorry, I missed the fact that you did cite that section, probably due to
it's lack of relevance.

The implementation I described conforms to the requirements of 7.20.3.1;
the (unspecified) value of SIZE_MAX is, indeed, as required by 7.20.3.1,
"the limit of size_t".

What I've repeatedly challenged you to provide is one or more citations
that say, directly or indirectly, that SIZE_MAX is the limit on the size
of objects. If they say it only indirectly, they should be accompanied
by an argument explaining how that conclusion may be derived from those
citations. All you've been doing is saying that this must be the case,
without addressing my arguments, or presenting any of your own.

I'll give you some help:

7.19p2 describes size_t: "the unsigned integer type of the result of the
sizeof operator". It does not describe it as a type with sufficient
range to store the size of any object.

6.5.3.4p2 specifies that "The sizeof operator yields the size (in bytes)
of its operand, which may be an expression or the parenthesized name of
a type. The size is determined from the type of the operand". It does
not say that arbitrary expressions which have not been passed to
sizeof() must have types small enough that sizeof() could express the
size of those types.

It does say that only the type of the expression is relevant in
determining the value yielded by "sizeof expression". Therefore, if
"sizeof expression" causes problems with 6.5.3.4p2, the problems are due
to the type of the expression, and can be fixed by changing that type;
they don't have anything to do with the value of that expression,
whether or not it is an lvalue expression referring to an actual object.
Those problems can therefore neither be avoided by having calloc()
return a null pointer value, nor caused by calloc() returning a non-null
pointer value. 6.5.3.4p2 therefore cannot constrain calloc() to return a
null pointer.

> We can disagree on whether I'm interpreting it correctly but I did
> provide it.  You even quoted it back to me in your message of 15 May
> at 2303Z.  Looking at snipped quotes in a response is not a good way
> to remember who said what :-)

Neither is looking at unsnipped quotes, when they get as long as they
would be if I'd failed to snip them.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Remving an element from Queue arnuld <sunrise@invalid.address> - 2012-05-08 08:09 +0000
  Re: Remving an element from Queue Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-08 08:01 -0400
    Re: Remving an element from Queue arnuld <sunrise@invalid.address> - 2012-05-09 05:43 +0000
      Re: Remving an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-08 23:21 -0700
        Re: Remving an element from Queue arnuld <sunrise@invalid.address> - 2012-05-09 09:27 +0000
          Re: Remving an element from Queue James Kuyper <jameskuyper@verizon.net> - 2012-05-09 07:54 -0400
        Re: Remving an element from Queue arnuld <sunrise@invalid.address> - 2012-05-09 13:18 +0000
          Re: Remving an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-09 10:59 -0700
            Re: Remving an element from Queue arnuld <arnuld.mizong@gmail.com> - 2012-05-10 05:26 -0700
              Re: Remving an element from Queue nick_keighley_nospam@hotmail.com - 2012-05-11 00:11 -0700
              Re: Remving an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-14 15:53 -0700
                Re: Remving an element from Queue lawrence.jones@siemens.com - 2012-05-15 17:42 -0400
                Re: Remving an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-15 16:40 -0700
                Re: Remving an element from Queue James Kuyper <jameskuyper@verizon.net> - 2012-05-15 23:03 -0400
                Re: Remving an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-15 20:38 -0700
                Re: Remving an element from Queue Jens Gustedt <jens.gustedt@loria.fr> - 2012-05-16 08:09 +0200
                Re: Remving an element from Queue James Kuyper <jameskuyper@verizon.net> - 2012-05-16 07:18 -0400
                Re: Remving an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-16 16:30 -0700
                Re: Remving an element from Queue James Kuyper <jameskuyper@verizon.net> - 2012-05-17 09:09 -0400
                Re: Remving an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-17 11:48 -0700
                Re: Removing an element from Queue James Kuyper <jameskuyper@verizon.net> - 2012-05-17 15:38 -0400
                Re: Removing an element from Queue Barry Schwarz <schwarzb@dqel.com> - 2012-05-17 15:21 -0700
                Re: Removing an element from Queue James Kuyper <jameskuyper@verizon.net> - 2012-05-17 19:08 -0400
                Re: Removing an element from Queue Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-19 09:05 -0700
                Re: Removing an element from Queue lawrence.jones@siemens.com - 2012-05-20 15:10 -0400
                Re: Removing an element from Queue Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-21 09:00 -0700
                Re: Remving an element from Queue Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-19 08:49 -0700
                Re: Remving an element from Queue Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-17 12:36 -0700
  Re: Remving an element from Queue nick_keighley_nospam@hotmail.com - 2012-05-08 05:09 -0700
    Re: Remving an element from Queue "BartC" <bc@freeuk.com> - 2012-05-08 14:03 +0100
      Re: Remving an element from Queue nick_keighley_nospam@hotmail.com - 2012-05-09 00:01 -0700
      Re: Remving an element from Queue nick_keighley_nospam@hotmail.com - 2012-05-09 00:03 -0700
        Re: Remving an element from Queue "BartC" <bc@freeuk.com> - 2012-05-09 10:37 +0100
          Re: Remving an element from Queue nick_keighley_nospam@hotmail.com - 2012-05-09 03:05 -0700
    Re: Remving an element from Queue arnuld <sunrise@invalid.address> - 2012-05-09 09:44 +0000
  Re: Remving an element from Queue Mark Bluemel <mark.bluemel@googlemail.com> - 2012-05-08 06:07 -0700
  Re: Remving an element from Queue Mark Bluemel <mark.bluemel@googlemail.com> - 2012-05-08 06:35 -0700
  Re: Remving an element from Queue Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-05-08 20:50 +0200
  Re: Remving an element from Queue 88888 Dihedral <dihedral88888@googlemail.com> - 2012-05-11 00:39 -0700

csiph-web