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

Groups > comp.lang.c > #20928

Re: Removing an element from Queue

Show all headers | View raw

[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?

>> fact an authoritative requirement, it would not impose a constraint on
>> SIZE_MAX; it only indirectly constrains either UINTMAX_MAX or LDBL_MAX,
>> whichever is larger. For example:
> 
> There is no requirement that size_t be the widest possible unsigned
> type. ...

Agreed.

> ...  Surely SIZE_MAX cannot exceed UINTMAX_MAX. ...

Agreed.

> ...  I don't understand
> how UINTMAX_MAX enters into this discussion.

Because uintmax_t and long double are the types whose limits determine
what "... sizeof ... can be used to compute ...", not size_t. That's
because the term "compute" is sufficiently vague to allow for a sizeof
expression that is no more than a sub-expression of an enclosing
expression with a result that is of some type other than size_t. The
maximum value that can be represented by such an enclosing expression is
either UINTMAX_MAX or LDBL_MAX, whichever is larger (almost certainly
LDBL_MAX). As long as the size can be correctly computed in one of those
types, with the sizeof operator playing some role somewhere in the
computation, then a hypothetical requirement that "... sizeof ... can be
used to compute the size of any object." would be satisfied.

>> 	char (*)p[SIZE_MAX] = calloc(2, SIZE_MAX);
>> 	long double size = 2.0L*sizeof *p;
>>
>> In that code, sizeof was indeed used to calculate the size of the object
>> (unless calloc() failed, in which case there is no object, but the size
>> calculation is unaffected by that fact).
> 
> While it is not very likely, it is possible for SIZE_MAX to exceed
> LDBL_MAX (1E37 bytes is a large object and size_t would need to be in
> excess of 120 bits).  In that case, the implicit conversion in your
> multiplication invokes undefined behavior (6.3.1.4-2). ...

For a hypothetical future version of the standard where there was, in
fact, a requirement that "... sizeof ... can be used to compute the size
of any object.", the existence of such a requirement would imply that a
conforming implementation of C where calloc(2,SIZE_MAX) returns a
non-null pointer must have either UINTMAX_MAX OR LDBL_MAX >= the size of
the object created by that call. Therefore, you could write:

    if(p)
    {
        #if UINTMAX_MAX/2 >= SIZE_MAX
	    uintmax_t size = 2LL * sizeof *p;
        #else
	    long double size = 2.0L * sizeof *p;
        #endif
	
        // do something with size.
    }

...
> 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 didn't address whether SIZE_MAX could be
> converted to a real floating type or any other integer type (though it
> seems obvious it should be convertible to a uintmax_t).

I wasn't talking about converting the size to another type; I was
talking about calculating the size in another type, because SIZE_MAX was
too small to be used for such calculations. Because such calculations
can be performed, a requirement that the computation be possible does
not greatly constrain the value of SIZE_MAX.

That was really intended as a kind of joke. Perhaps I should have
inserted a smiley, but I thought that it was neither sufficiently funny
nor sufficiently obscure to require a smiley. I guess I was wrong on
that second part. All I was trying to do was point out that "... can be
used to compute ..." is too vague a phrase to be used in a specification
that would mean what you wanted it to mean.

> 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.

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