Path: utzoo!attcan!uunet!husc6!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.std.c
Subject: Re: size_t
Message-ID: <975@cbnewsl.ATT.COM>
Date: 1 Jul 89 14:43:19 GMT
References: <934@tukki.jyu.fi> <845@cbnewsl.ATT.COM> <941@tukki.jyu.fi>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 74

In article <941@tukki.jyu.fi> tarvaine@tukki.jyu.fi (Tapani Tarvainen) writes:
>In article <845@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes:
>>Section 4.1.5 of the pANS:
>>
>>	The types [defined in <stddef.h>] are ...
>>
>>		size_t
>>
>>	which is the unsigned integral type of the result of the sizeof
>>	operator ...
>>
>>It is also defined in <stdio.h>, <stdlib.h>, <string.h> and <time.h>.
>
>If this is all pANS says about it, TurboC's behaviour is legal.
>As static objects can't exceed 64K, sizeof result will always
>fit in unsigned int; but in huge model one can have a dynamic
>array with more than 64K elements.

That is essentially all that the pANS says directly about size_t, but
that doesn't mean that you can draw the following conclusions.  The
sizeof operator must be able to express the size, in bytes, of any
object created by a strictly conforming program.  If such a program can
allocate an object at runtime through malloc, calloc, or realloc that
is too big for the sizeof operator, then the implementation is not
conforming.  Since the constraints for size_t are the same as for
sizeof (at least in terms of representation), size_t must be big enough
to hold the number of bytes of any validly created object.

>Therefore:
>
>What should be done when one has an array whose indices may not fit
>in an int?  Is there a suitable type for that in pANS?

By the pANS, size_t should work, for any strictly conforming program.
Of course, if there is a "hugealloc()" function provided which is the
only access to objects that are bigger than what sizeof or size_t can
describe, this is still a conforming implementation.  If a program
makes use of such a function, then a larger than size_t integral type
would be necessary.

>
>If I use long, TC will warn that "Conversion may lose significant digits"
>every time in models other than huge, not to mention that it is waste
>of resources, but in huge model int won't do.
>Suggestions, anyone?

I, personally, dislike compilers that try to be "lint" at the same time,
but that may be my UNIX system biases showing through.  A conversion of
a larger integral type to a smaller unsigned type (such as size_t) is
well defined, even if the value being converted doesn't "fit".  It may
be that TC will be quiet if you put an explicit cast on the assignments.

>
>(BTW, thank you David for informative answers, even though the info on
>realloc was somewhat unfortunate: it seems I'll need an extra variable
>for every pointer to the buffer that is reallocated.)

I've found that often it is better to use pointers to such buffers only
in local situations and to keep only offsets in the shared (file scope)
parts.  When a buffer is then realloc()ed, there are no readjustments of
a slew of pointers.

Another favorite approach is to determine, if possible, the maximum
extent necessary for the buffer based on early information (for example,
by knowing the size of the input file), and never needing to grow the
buffer at all.  This can save a lot of program complexity.

>
>
>-- 
>Tapani Tarvainen                 BitNet:    tarvainen@finjyu
>Internet:  tarvainen@jylk.jyu.fi  -- OR --  tarvaine@tukki.jyu.fi

Dave Prosser	...not an official X3J11 answer...