Re: size of

Discussion in 'C Programming' started by Keith Thompson, Aug 13, 2013.

  1. Raj Pashwar <> writes:
    > I am struggling to find, in my C implementation, which header contains
    > the sizeof() function. Should it be stdlib.h? Or somewhere else?


    sizeof is not a function, so it's not defined in any header.

    It's a built-in operator (whose name happens to be a keyword, unlike
    most other operators whose names consist of punctuation characters).

    It's implemented by the compiler, not by the library.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 13, 2013
    #1
    1. Advertising

  2. Keith Thompson

    Ike Naar Guest

    On 2013-08-13, Keith Thompson <> wrote:
    > Raj Pashwar <> writes:
    >> I am struggling to find, in my C implementation, which header contains
    >> the sizeof() function. Should it be stdlib.h? Or somewhere else?

    >
    > sizeof is not a function, so it's not defined in any header.
    >
    > It's a built-in operator (whose name happens to be a keyword, unlike
    > most other operators whose names consist of punctuation characters).
    >
    > It's implemented by the compiler, not by the library.


    Although it's peculiar that sizeof's result type, size_t, is not built-in.
    To make size_t known to the program, at least <stddef.h> needs to be included.
    So this compiles okay:

    int main(void)
    {
    return sizeof (double) == 0; /* returns 0 */
    }

    but here the #include <stddef.h> is mandatory

    #include <stddef.h>
    int main(void)
    {
    return sizeof (double) == (size_t) 0; /* returns 0 */
    }

    (Note: other headers, e.g. <stdio.h>, <stdlib.h> define size_t as well).
     
    Ike Naar, Aug 13, 2013
    #2
    1. Advertising

  3. Ike Naar <> writes:
    > On 2013-08-13, Keith Thompson <> wrote:
    >> Raj Pashwar <> writes:
    >>> I am struggling to find, in my C implementation, which header contains
    >>> the sizeof() function. Should it be stdlib.h? Or somewhere else?

    >>
    >> sizeof is not a function, so it's not defined in any header.
    >>
    >> It's a built-in operator (whose name happens to be a keyword, unlike
    >> most other operators whose names consist of punctuation characters).
    >>
    >> It's implemented by the compiler, not by the library.

    >
    > Although it's peculiar that sizeof's result type, size_t, is not built-in.
    > To make size_t known to the program, at least <stddef.h> needs to be included.
    > So this compiles okay:
    >
    > int main(void)
    > {
    > return sizeof (double) == 0; /* returns 0 */
    > }
    >
    > but here the #include <stddef.h> is mandatory
    >
    > #include <stddef.h>
    > int main(void)
    > {
    > return sizeof (double) == (size_t) 0; /* returns 0 */
    > }
    >
    > (Note: other headers, e.g. <stdio.h>, <stdlib.h> define size_t as well).


    The type yielded by sizeof *is* built-in. It's not the same type for
    all implementations, but it is one of the built-in unsigned types,
    typically either unsigned int or unsigned long.

    size_t is a typedef. As such, it's not a distinct type, just another
    name for some existing type, provided for programmer convenience.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 13, 2013
    #3
  4. On Tuesday, August 13, 2013 11:49:31 PM UTC+1, Keith Thompson wrote:
    > Ike Naar <> writes:
    >
    > size_t is a typedef. As such, it's not a distinct type, just another
    > name for some existing type, provided for programmer convenience.
    >

    It's a typedef, but you have to use it if you want code to be portable,
    because you don't know what it will alias to. But in fact most sizes are
    small, and can safely be assigned to int.
     
    Malcolm McLean, Aug 14, 2013
    #4
  5. Malcolm McLean <> writes:
    > On Tuesday, August 13, 2013 11:49:31 PM UTC+1, Keith Thompson wrote:
    >> Ike Naar <> writes:
    >>
    >> size_t is a typedef. As such, it's not a distinct type, just another
    >> name for some existing type, provided for programmer convenience.
    >>

    > It's a typedef, but you have to use it if you want code to be portable,
    > because you don't know what it will alias to.


    True -- that's why size_t exists.

    > But in fact most sizes are
    > small, and can safely be assigned to int.


    But in fact *all* sizes can safely be assigned to a size_t.

    You can use int, which works most of the time, or you can use size_t,
    which *always* works. Decisions, decisions.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 14, 2013
    #5
  6. Kelsey Bjarnason <> writes:
    > On Wed, 14 Aug 2013 08:22:35 -0700, Malcolm McLean wrote:
    >> On Tuesday, August 13, 2013 11:49:31 PM UTC+1, Keith Thompson wrote:
    >>> Ike Naar <> writes:
    >>>
    >>> size_t is a typedef. As such, it's not a distinct type, just another
    >>> name for some existing type, provided for programmer convenience.
    >>>

    >> It's a typedef, but you have to use it if you want code to be portable,
    >> because you don't know what it will alias to. But in fact most sizes are
    >> small, and can safely be assigned to int.

    >
    > And some are small enough to fit in char, and sometimes char is big
    > enough to handle any usable size value. And in every single case, size_t
    > will do the job properly, something which cannot be said of any other
    > alternative.


    Except for uintmax_t, but that's hardly better (for this purpose) than
    size_t.

    > Unless, of course, you've discovered a means to create objects of
    > negative size, in which case I'd like the technique; it's likely cheaper
    > than installing several gigs more ram.


    Memory leaks could be interesting.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 14, 2013
    #6
  7. Keith Thompson

    Ken Brody Guest

    On 8/14/2013 4:20 PM, Kelsey Bjarnason wrote:
    [...]
    > Unless, of course, you've discovered a means to create objects of
    > negative size, in which case I'd like the technique; it's likely cheaper
    > than installing several gigs more ram.


    The above reminded me of a poem I hear $(MANY) years ago, where a carpenter
    describes the results of building a box with sides of length negative-one.

    Alas, my Google-fu is weak today, and I can't find it online.

    --
    Kenneth BRody
     
    Ken Brody, Aug 15, 2013
    #7
  8. On Wednesday, August 14, 2013 9:20:16 PM UTC+1, Kelsey Bjarnason wrote:
    > On Wed, 14 Aug 2013 08:22:35 -0700, Malcolm McLean wrote:
    >
    >
    > Unless, of course, you've discovered a means to create objects of
    > negative size, in which case I'd like the technique; it's likely cheaper
    > than installing several gigs more ram.
    >

    The size of a raster in a given image format will be the size of an image,
    minus the size of the header.
    So
    size_t imagesize;
    size_t rasterbytes;
    size_t i;

    loadimage( ..., &imagesize);
    rasterbytes = imagesize - sizeof(ImageHeader);
    for(i=0;i<rasterbytes;i++)
    printf("rasterbyte %z is %02x\n", i, image[sizeof(ImageHeader) + i]);

    All reasonable?
     
    Malcolm McLean, Aug 15, 2013
    #8
  9. Keith Thompson

    Ken Brody Guest

    On 8/15/2013 11:11 AM, Azazel wrote:
    > On 2013-08-15, Ken Brody <> wrote:
    >> On 8/14/2013 4:20 PM, Kelsey Bjarnason wrote: [...]
    >>> Unless, of course, you've discovered a means to create objects of
    >>> negative size, in which case I'd like the technique; it's likely
    >>> cheaper than installing several gigs more ram.

    >>
    >> The above reminded me of a poem I hear $(MANY) years ago, where a
    >> carpenter describes the results of building a box with sides of length
    >> negative-one.
    >>
    >> Alas, my Google-fu is weak today, and I can't find it online.

    >
    > http://paulbourke.net/fun/minus1.html


    That's the one. Thanks.
     
    Ken Brody, Aug 16, 2013
    #9
  10. On Friday, August 16, 2013 5:03:28 PM UTC+1, Kelsey Bjarnason wrote:
    > On Thu, 15 Aug 2013 08:54:53 -0700, Malcolm McLean wrote:
    >
    > > So size_t imagesize;
    > > size_t rasterbytes;
    > > size_t i;

    >
    >
    > > loadimage( ..., &imagesize);
    > > rasterbytes = imagesize - sizeof(ImageHeader);

    >
    > > for(i=0;i<rasterbytes;i++)
    > > printf("rasterbyte %z is %02x\n", i, image[sizeof(ImageHeader) + i]);

    >
    > > All reasonable?

    >
    >
    > Well, let's see. No idea what "loadimage" does, say, in cases of failure
    > or where the image is in fact larger than the capacity of a size_t to
    > represent (16-bit implementations, multi-gig images?).
    >

    Well if imagesize is a positive integer, and the function is correctly
    written, then you can assume that an object of that size has been successfully
    loaded into memory.
    I agree that use of a size_t makes it difficult to distinguish the error
    case from the empty case. Some OSs do allow files of length zero.
    >
    > Okay, so, it looks to me like poor error handling plus poor evaluation of
    > loop indexes. What has that got to do with some bizarre argument about
    > not using size_t for sizes?
    >

    What happens if we use an int instead?

    If this was real code, what environment would you expect to see it in?
     
    Malcolm McLean, Aug 16, 2013
    #10
  11. Keith Thompson

    James Kuyper Guest

    On 08/16/2013 05:36 PM, Malcolm McLean wrote:
    > On Friday, August 16, 2013 5:03:28 PM UTC+1, Kelsey Bjarnason wrote:
    >> On Thu, 15 Aug 2013 08:54:53 -0700, Malcolm McLean wrote:
    >>
    >>> So size_t imagesize;
    >>> size_t rasterbytes;
    >>> size_t i;

    >>
    >>
    >>> loadimage( ..., &imagesize);
    >>> rasterbytes = imagesize - sizeof(ImageHeader);

    >>
    >>> for(i=0;i<rasterbytes;i++)
    >>> printf("rasterbyte %z is %02x\n", i, image[sizeof(ImageHeader) + i]);

    >>
    >>> All reasonable?

    >>
    >>
    >> Well, let's see. No idea what "loadimage" does, say, in cases of failure
    >> or where the image is in fact larger than the capacity of a size_t to
    >> represent (16-bit implementations, multi-gig images?).
    >>

    > Well if imagesize is a positive integer, and the function is correctly
    > written, then you can assume that an object of that size has been successfully
    > loaded into memory.
    > I agree that use of a size_t makes it difficult to distinguish the error
    > case from the empty case. Some OSs do allow files of length zero.
    >>
    >> Okay, so, it looks to me like poor error handling plus poor evaluation of
    >> loop indexes. What has that got to do with some bizarre argument about
    >> not using size_t for sizes?
    >>

    > What happens if we use an int instead?


    With proper validity checks inserted? Pretty much the same thing that
    happens if you use size_t, except that it cannot be used with images
    larger than INT_MAX.

    > If this was real code, what environment would you expect to see it in?


    There's not enough details to be sure; but there's a pretty good chance
    that it's one where INT_MAX wouldn't be big enough.
     
    James Kuyper, Aug 16, 2013
    #11
  12. On Saturday, August 17, 2013 5:50:14 AM UTC+1, Kelsey Bjarnason wrote:
    > On Fri, 16 Aug 2013 14:36:33 -0700, Malcolm McLean wrote:
    >
    > > Well if imagesize is a positive integer, and the function is correctly
    > > written, then you can assume that an object of that size has been
    > > successfully loaded into memory.

    >
    > In which case, if you're using an int or an unsigned int, rather than a
    > size_t to handle sizes, you're creating failure conditions when the size
    > exceeds the bounds of your integer type, which should have been size_t.
    >

    int should be the natural integer size for the machine. Usually we can live
    with the fact that it can only index 2GB of memory. Since it's signed,
    a decent platform can give an overflow error if we attempt to assign a
    result with is too large to one. Because of a quirk in the C standard, this
    isn't allowed for a size_t. So if loadimage() contains a loop like
    while( (ch = fgetc(fp)) ! EOF) N++;
    N must wrap on overflow. It's not allowed to behave any differently.
    >
    > > I agree that use of a size_t makes it difficult to distinguish the error
    > > case from the empty case. Some OSs do allow files of length zero.

    >
    > Improper code design is not an argument against size_t, it's an argument
    > against writing code that way.
    >

    If a language is Turing equivalent than, by definition, it's possible to write
    correct programs in that language. That doesn't shut down all discussions
    about possible errors that a human programmer is likely to introduce,
    because of badly designed features.
    >
    > > If this was real code, what environment would you expect to see it in?

    >
    > None whatsoever, ideally. Not unless it is backed by a largish set of
    > fundamental requirements, none of which are thus far documented here,
    > which would render the issues raised moot or largely so.
    >

    It would be running in a casual debug/ testing environment. You can't document and acceptance test all your testing code, or you create an infinite regression.
    So it's very likely that loadimage() has an error, and is being debugged.
    That's why someone wants to print out the raster bytes. So it's not a stretch
    to suppose that the size it returns is actually less than the size of the
    header.
     
    Malcolm McLean, Aug 17, 2013
    #12
  13. On 17-Aug-13 05:21, Malcolm McLean wrote:
    > On Saturday, August 17, 2013 5:50:14 AM UTC+1, Kelsey Bjarnason
    > wrote:
    >> In which case, if you're using an int or an unsigned int, rather
    >> than a size_t to handle sizes, you're creating failure conditions
    >> when the size exceeds the bounds of your integer type, which should
    >> have been size_t.

    >
    > int should be the natural integer size for the machine. Usually we
    > can live with the fact that it can only index 2GB of memory.


    int is not guaranteed to be able to index more than 64kB of memory,
    which is hardly sufficient for modern purposes. Even a 2GB limit
    frequently causes problems these days.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
     
    Stephen Sprunk, Aug 17, 2013
    #13
  14. On Saturday, August 17, 2013 3:33:53 PM UTC+1, Stephen Sprunk wrote:
    > On 17-Aug-13 05:21, Malcolm McLean wrote:
    >
    > int is not guaranteed to be able to index more than 64kB of memory,
    > which is hardly sufficient for modern purposes. Even a 2GB limit
    > frequently causes problems these days.
    >

    int should be the natural integer size for the machine. This policy was
    followed as machines moved from 16 bit to 32 bit, and int became 32 bits.
    16 bit machines still exist, but they demand convolutions to support objects
    bigger than 64K, if they support them at all, so it's reasonable to say
    that a special index type must be used if you're doing this.

    Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a bit
    of a problem, because number of times you have more than 2 billion entities
    is quite small, but not small enough to be negligible.
    So usually we can use int i as a general-purpose index, but not always. Which
    causes problems when trying to write clean code.
     
    Malcolm McLean, Aug 17, 2013
    #14
  15. Malcolm McLean <> writes:

    > On Saturday, August 17, 2013 3:33:53 PM UTC+1, Stephen Sprunk wrote:
    >> On 17-Aug-13 05:21, Malcolm McLean wrote:
    >>
    >> int is not guaranteed to be able to index more than 64kB of memory,
    >> which is hardly sufficient for modern purposes. Even a 2GB limit
    >> frequently causes problems these days.
    >>

    > int should be the natural integer size for the machine. This policy was
    > followed as machines moved from 16 bit to 32 bit, and int became 32 bits.
    > 16 bit machines still exist, but they demand convolutions to support objects
    > bigger than 64K, if they support them at all, so it's reasonable to say
    > that a special index type must be used if you're doing this.
    >
    > Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a bit
    > of a problem, because number of times you have more than 2 billion entities
    > is quite small, but not small enough to be negligible.
    > So usually we can use int i as a general-purpose index, but not always. Which
    > causes problems when trying to write clean code.


    However, one /can/ use size_t as a general-purpose index. I understand
    you don't like the semantics of unsigned types in C, but you have not
    made a good case that the code you get when you use them is "unclean".

    --
    Ben.
     
    Ben Bacarisse, Aug 17, 2013
    #15
  16. Keith Thompson

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Ike Naar <> writes:
    >> On 2013-08-13, Keith Thompson <> wrote:
    >>> Raj Pashwar <> writes:
    >>>> I am struggling to find, in my C implementation, which header
    >>>> contains the sizeof() function. Should it be stdlib.h? Or
    >>>> somewhere else?
    >>>
    >>> sizeof is not a function, so it's not defined in any header.
    >>>
    >>> It's a built-in operator (whose name happens to be a keyword,
    >>> unlike most other operators whose names consist of punctuation
    >>> characters).
    >>>
    >>> It's implemented by the compiler, not by the library.

    >>
    >> Although it's peculiar that sizeof's result type, size_t, is not
    >> built-in. To make size_t known to the program, at least <stddef.h>
    >> needs to be included. So this compiles okay:
    >>
    >> int main(void)
    >> {
    >> return sizeof (double) == 0; /* returns 0 */
    >> }
    >>
    >> but here the #include <stddef.h> is mandatory
    >>
    >> #include <stddef.h>
    >> int main(void)
    >> {
    >> return sizeof (double) == (size_t) 0; /* returns 0 */
    >> }
    >>
    >> (Note: other headers, e.g. <stdio.h>, <stdlib.h> define size_t as
    >> well).

    >
    > The type yielded by sizeof *is* built-in. It's not the same type
    > for all implementations, but it is one of the built-in unsigned
    > types, typically either unsigned int or unsigned long.


    Just a small clarification. The type yielded by sizeof is
    defined by the implementation, and it is an unsigned integer
    type, but it need not be a standard integer types; it could
    instead be an extended unsigned integer type, which still are
    types defined by the implementation, but do not belong to the set
    of standard integer types.[*] (I know you know the difference,
    am clarifying just for the benefit of other readers.)

    > size_t is a typedef. As such, it's not a distinct type, just
    > another name for some existing type, provided for programmer
    > convenience.


    Another clarification. Typically it's true that 'size_t' is
    defined using typedef, but that doesn't have to be so; it may be
    defined using implemention-specific magic instead. Also, it is
    true in some sense that the type named by 'size_t' is an existing
    type, but that type need not be nameable in any other way; to say
    that another way, the type named by 'size_t' could be distinct
    from any type that can be referenced (eg, in a cast operation)
    without using 'size_t'.[*]


    [*] C90 doesn't have extended integer types so these comments
    don't apply in C90.
     
    Tim Rentsch, Aug 19, 2013
    #16
  17. On 18-Aug-13 02:22, Rosario1903 wrote:
    > i would do something as:
    > ...
    > /*
    > if big array
    > if sys is not able to address array of len of a number
    > of 64 bit stop
    > */
    >
    > if(sizeof(size_t)*CHAR_BIT< 64)
    > error();
    > ...
    > for me size_t cold be useful only to see if machine can
    > address 64 bit array


    Why not just always use size_t and let the compiler take care of
    ensuring it's large enough to index the largest arrays that the
    implementation can create--be that 16, 32, 64 or some other number of bits?

    Why insist on a 64-bit size_t, for instance, if the implementation
    you're compiling on doesn't support arrays larger than 2GB anyway?

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
     
    Stephen Sprunk, Aug 20, 2013
    #17
  18. On Tuesday, August 20, 2013 2:42:19 AM UTC+1, Stephen Sprunk wrote:
    > On 18-Aug-13 02:22, Rosario1903 wrote:
    >
    > Why not just always use size_t and let the compiler take care of
    > ensuring it's large enough to index the largest arrays that the
    > implementation can create--be that 16, 32, 64 or some other number of bits?
    >

    Because of the plug and socket problem. If you could train everyone to be
    absolutely consistent in using size_t for an index variable, then that
    solution would be viable. But people won't, largely because of the choice
    of name, and the underscore.
    If you've got a function that returns an array of employees, and its
    size, people might write

    EMPLOYEE *getemployees(int *N);
    or
    EMPLOYEE *getemployees(size_t *N);

    it's most unlikely that the number of employees will exceed the range of an
    int, but, technically, int is only guaranteed 16 bits, and some companies
    have more that 32768 employees.

    You find yourself writing code like

    size_t *intarraytosize_t(int *x, size_t N);

    just to code round the interfaces. Or worse, someone will say "size_t is really
    just an int, so I'll save myself the bother. (size_t *)x".
     
    Malcolm McLean, Aug 20, 2013
    #18
  19. Keith Thompson

    Ian Collins Guest

    Rosario1903 wrote:
    > On Mon, 19 Aug 2013 20:42:19 -0500, Stephen Sprunk
    > <> wrote:
    >
    >> On 18-Aug-13 02:22, Rosario1903 wrote:
    >>> i would do something as:
    >>> ...
    >>> /*
    >>> if big array
    >>> if sys is not able to address array of len of a number
    >>> of 64 bit stop
    >>> */
    >>>
    >>> if(sizeof(size_t)*CHAR_BIT< 64)
    >>> error();
    >>> ...
    >>> for me size_t cold be useful only to see if machine can
    >>> address 64 bit array

    >>
    >> Why not just always use size_t and let the compiler take care of
    >> ensuring it's large enough to index the largest arrays that the
    >> implementation can create--be that 16, 32, 64 or some other number of bits?

    >
    > in my vew, i not would use size_t because i don't know the value
    > sizeof(size_t)*CHAR_BIT
    > because each machine can be one different value


    That's the point. What's the use of a 64 bit size_t on a 16 bit machine?

    > and so UBs


    Where?

    >> Why insist on a 64-bit size_t, for instance, if the implementation
    >> you're compiling on doesn't support arrays larger than 2GB anyway?

    >
    > because Malcolm said:
    > "Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a
    > bit
    > of a problem, because number of times you have more than 2 billion
    > entities
    > is quite small, but *not small enough to be negligible*."
    >
    > where i wrote the 2 *


    He's talking about int, not size_t.

    > yes 64 could be oo much possible sizeof(size_t)== 40 bit etc
    > but it seem odd..
    > the code i post is a little sloppy the code i mean is this:
    >
    > uint64_t i, len;
    > uint8_t *p;
    >
    > len=f();
    >
    > if(len > SIZE_TMAX) goto error()


    How can a value be bigger than its maximum value?

    --
    Ian Collins
     
    Ian Collins, Aug 20, 2013
    #19
  20. Keith Thompson

    Ian Collins Guest

    Malcolm McLean wrote:
    > On Tuesday, August 20, 2013 2:42:19 AM UTC+1, Stephen Sprunk wrote:
    >> On 18-Aug-13 02:22, Rosario1903 wrote:
    >>
    >> Why not just always use size_t and let the compiler take care of
    >> ensuring it's large enough to index the largest arrays that the
    >> implementation can create--be that 16, 32, 64 or some other number of bits?
    >>

    > Because of the plug and socket problem. If you could train everyone to be
    > absolutely consistent in using size_t for an index variable, then that
    > solution would be viable. But people won't, largely because of the choice
    > of name, and the underscore.
    > If you've got a function that returns an array of employees, and its
    > size, people might write
    >
    > EMPLOYEE *getemployees(int *N);
    > or
    > EMPLOYEE *getemployees(size_t *N);
    >
    > it's most unlikely that the number of employees will exceed the range of an
    > int, but, technically, int is only guaranteed 16 bits, and some companies
    > have more that 32768 employees.
    >
    > You find yourself writing code like
    >
    > size_t *intarraytosize_t(int *x, size_t N);
    >
    > just to code round the interfaces. Or worse, someone will say "size_t is really
    > just an int, so I'll save myself the bother. (size_t *)x".


    Why? This doesn't make a lot of sense. I've never seen anyone do what
    you say and if they did, it certainly wouldn't get through a code review.

    --
    Ian Collins
     
    Ian Collins, Aug 20, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Madhanmohan S
    Replies:
    5
    Views:
    7,842
    Madhanmohan S
    Sep 3, 2004
  2. Andreas Klemt
    Replies:
    6
    Views:
    11,412
    Peter Theill
    Nov 28, 2004
  3. =?Utf-8?B?QmlkYXJrb3Rh?=

    How to set the DataGrid Row Size to a fixed size.

    =?Utf-8?B?QmlkYXJrb3Rh?=, May 19, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    859
    =?Utf-8?B?QmlkYXJrb3Rh?=
    May 19, 2005
  4. Neil Zanella
    Replies:
    4
    Views:
    513
    Gianni Mariani
    Oct 9, 2003
  5. Jason Cavett

    Preferred Size, Minimum Size, Size

    Jason Cavett, May 23, 2008, in forum: Java
    Replies:
    5
    Views:
    12,742
    Michael Jung
    May 25, 2008
Loading...

Share This Page