size_t problems

Discussion in 'C Programming' started by jacob navia, Aug 29, 2007.

  1. jacob navia

    jacob navia Guest

    I am trying to compile as much code in 64 bit mode as
    possible to test the 64 bit version of lcc-win.

    The problem appears now that size_t is now 64 bits.

    Fine. It has to be since there are objects that are more than 4GB
    long.

    The problem is, when you have in thousands of places

    int s;

    // ...
    s = strlen(str) ;

    Since strlen returns a size_t, we have a 64 bit result being
    assigned to a 32 bit int.

    This can be correct, and in 99.9999999999999999999999999%
    of the cases the string will be smaller than 2GB...

    Now the problem:

    Since I warn each time a narrowing conversion is done (since
    that could loose data) I end up with hundreds of warnings each time
    a construct like int a = strlen(...) appears. This clutters
    everything, and important warnings go lost.


    I do not know how to get out of this problem. Maybe any of you has
    a good idea? How do you solve this when porting to 64 bits?

    jacob
    jacob navia, Aug 29, 2007
    #1
    1. Advertising

  2. "jacob navia" <> wrote in message
    news:46d5c46d$0$5108$...
    >I am trying to compile as much code in 64 bit mode as
    > possible to test the 64 bit version of lcc-win.
    >
    > The problem appears now that size_t is now 64 bits.
    >
    > Fine. It has to be since there are objects that are more than 4GB
    > long.
    >
    > The problem is, when you have in thousands of places
    >
    > int s;
    >
    > // ...
    > s = strlen(str) ;
    >
    > Since strlen returns a size_t, we have a 64 bit result being
    > assigned to a 32 bit int.
    >
    > This can be correct, and in 99.9999999999999999999999999%
    > of the cases the string will be smaller than 2GB...
    >
    > Now the problem:
    >
    > Since I warn each time a narrowing conversion is done (since
    > that could loose data) I end up with hundreds of warnings each time
    > a construct like int a = strlen(...) appears. This clutters
    > everything, and important warnings go lost.
    >
    >
    > I do not know how to get out of this problem. Maybe any of you has
    > a good idea? How do you solve this when porting to 64 bits?
    >

    There's a very obvious answer to that one. As a compiler-writer, youa re in
    a position to do it.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Aug 29, 2007
    #2
    1. Advertising

  3. jacob navia wrote:
    [... "64-bit compiler" with 64-bit size_t ...]
    > The problem is, when you have in thousands of places
    >
    > int s;
    >
    > // ...
    > s = strlen(str) ;
    >
    > Since strlen returns a size_t, we have a 64 bit result being
    > assigned to a 32 bit int.
    >
    > This can be correct, and in 99.9999999999999999999999999%
    > of the cases the string will be smaller than 2GB...
    >
    > Now the problem:
    >
    > Since I warn each time a narrowing conversion is done (since
    > that could loose data) I end up with hundreds of warnings each time
    > a construct like int a = strlen(...) appears. This clutters
    > everything, and important warnings go lost.
    >
    > I do not know how to get out of this problem. Maybe any of you has
    > a good idea? How do you solve this when porting to 64 bits?


    Well, some people will probably claim that those hundreds of warnings
    are a good thing, as strlen() returns size_t and not int. However,
    if you are bombarded with hundreds of such warnings, many people will
    simply start ignoring all of the warnings, and the "real" ones will
    be lost in the noise.

    Perhaps a flag that says "only display the first N instances of this
    warning"?

    Perhaps you could make int 64 bits as well?

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Aug 29, 2007
    #3
  4. jacob navia

    Ben Pfaff Guest

    jacob navia <> writes:

    > I am trying to compile as much code in 64 bit mode as
    > possible to test the 64 bit version of lcc-win.
    >
    > The problem appears now that size_t is now 64 bits.
    >
    > Fine. It has to be since there are objects that are more than 4GB
    > long.
    >
    > The problem is, when you have in thousands of places
    >
    > int s;
    >
    > // ...
    > s = strlen(str) ;
    >
    > Since strlen returns a size_t, we have a 64 bit result being
    > assigned to a 32 bit int.


    I'd suggest fixing the code that does this to use size_t instead
    of int. size_t is correct. int is, at best, an approximation to
    correct. We've just had a pretty long thread with Malcolm McLean
    discussing this very topic; perhaps you should refer to that
    thread, if you're not already aware of it.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
    Ben Pfaff, Aug 29, 2007
    #4
  5. jacob navia <> writes:
    > I am trying to compile as much code in 64 bit mode as
    > possible to test the 64 bit version of lcc-win.
    >
    > The problem appears now that size_t is now 64 bits.
    >
    > Fine. It has to be since there are objects that are more than 4GB
    > long.
    >
    > The problem is, when you have in thousands of places
    >
    > int s;
    >
    > // ...
    > s = strlen(str) ;
    >
    > Since strlen returns a size_t, we have a 64 bit result being
    > assigned to a 32 bit int.
    >
    > This can be correct, and in 99.9999999999999999999999999%
    > of the cases the string will be smaller than 2GB...
    >
    > Now the problem:
    >
    > Since I warn each time a narrowing conversion is done (since
    > that could loose data) I end up with hundreds of warnings each time
    > a construct like int a = strlen(...) appears. This clutters
    > everything, and important warnings go lost.
    >
    >
    > I do not know how to get out of this problem. Maybe any of you has
    > a good idea? How do you solve this when porting to 64 bits?


    Why didn't you get the same warnings in 32-bit mode? If int and
    size_t are both 32 bits, INT_MAX < SIZE_MAX, and there are values of
    size_t that cannot be stored in an int. If the "narrowing conversion"
    warning is based on the sizes of the type rather than the ranges, I'd
    say you've just discovered a compiler bug.

    If you're getting hundreds of warnings, it's because you have hundreds
    of instances of potential loss of information.

    Note that a conversion to a signed type of a value that doesn't fit in
    that type yields an implementation-defined result (or, in C99, raises
    an implementation-defined signal). In theory, the result could be
    more than just a loss of information.

    The problem is to distinguish cases where the conversion can't
    actually overflow at execution times from the cases where it can.

    Sufficiently clever dataflow analysis in the compiler might eliminate
    some of the errors. If, given
    int s = strlen(str);
    the compiler knows enough about how the value of str that it can be
    sure it's no longer than INT_MAX bytes, it can eliminate the warning.
    But I don't know if it's practical, or even possible to eliminate
    enough of the warnings this way. Doing this in most cases is hard;
    doing it in all cases might be equivalent to solving the halting
    problem. (That latter is only a guess.)

    (Making int 64 bits won't solve the problem, since INT_MAX will still
    be less than SIZE_MAX.)

    You can filter the compiler's output to eliminate warnings about
    narrowing implicit conversions (or, if available, use a compiler
    option to turn off that particular warning), but that could miss cases
    that could actually overflow.

    In my opinion, the warnings are legitimate. The ideal solution is not
    to suppress them, but to fix the code, assigning the result of
    strlen() to a size_t rather than to an int. (Or I suppose you could
    use a cast to shut up the compiler if you're *certain* the result can
    never exceed INT_MAX, but that's not what I'd do.)

    By compiling the code in 64-bit mode, you've discovered a number of
    dormant bugs in the code.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 29, 2007
    #5
  6. "Malcolm McLean" <> writes:
    > "jacob navia" <> wrote in message
    > news:46d5c46d$0$5108$...

    [...]
    >>I am trying to compile as much code in 64 bit mode as
    >> possible to test the 64 bit version of lcc-win.
    >>
    >> The problem appears now that size_t is now 64 bits.

    [...]

    >> int s;
    >>
    >> // ...
    >> s = strlen(str) ;
    >>
    >> Since strlen returns a size_t, we have a 64 bit result being
    >> assigned to a 32 bit int.
    >>
    >> This can be correct, and in 99.9999999999999999999999999%
    >> of the cases the string will be smaller than 2GB...
    >>
    >> Now the problem:
    >>
    >> Since I warn each time a narrowing conversion is done (since
    >> that could loose data) I end up with hundreds of warnings each time
    >> a construct like int a = strlen(...) appears. This clutters
    >> everything, and important warnings go lost.
    >>
    >>
    >> I do not know how to get out of this problem. Maybe any of you has
    >> a good idea? How do you solve this when porting to 64 bits?
    >>

    > There's a very obvious answer to that one. As a compiler-writer, youa
    > re in a position to do it.


    I presume the solution you're suggesting is to make int 64 bits. How
    does this help? strlen() still returns size_t, and if int and size_t
    are both 64 bits, there will still be size_t values that cannot be
    stored in an int.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 29, 2007
    #6
  7. "Ben Pfaff" <> wrote in message
    news:...
    > I'd suggest fixing the code that does this to use size_t instead
    > of int. size_t is correct. int is, at best, an approximation to
    > correct. We've just had a pretty long thread with Malcolm McLean
    > discussing this very topic; perhaps you should refer to that
    > thread, if you're not already aware of it.
    >

    Yup. As I said, if people would use size_t consistently for every single
    calculation that ultimately ends up in an array index there wouldn't be such
    a problem. The reality is that people won't, and lots of code doesn't.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Aug 29, 2007
    #7
  8. "Keith Thompson" <> wrote in message
    news:...
    > "Malcolm McLean" <> writes:
    >> "jacob navia" <> wrote in message
    >> news:46d5c46d$0$5108$...

    > [...]
    >>>I am trying to compile as much code in 64 bit mode as
    >>> possible to test the 64 bit version of lcc-win.
    >>>
    >>> The problem appears now that size_t is now 64 bits.

    > [...]
    >
    >>> int s;
    >>>
    >>> // ...
    >>> s = strlen(str) ;
    >>>
    >>> Since strlen returns a size_t, we have a 64 bit result being
    >>> assigned to a 32 bit int.
    >>>
    >>> This can be correct, and in 99.9999999999999999999999999%
    >>> of the cases the string will be smaller than 2GB...
    >>>
    >>> Now the problem:
    >>>
    >>> Since I warn each time a narrowing conversion is done (since
    >>> that could loose data) I end up with hundreds of warnings each time
    >>> a construct like int a = strlen(...) appears. This clutters
    >>> everything, and important warnings go lost.
    >>>
    >>>
    >>> I do not know how to get out of this problem. Maybe any of you has
    >>> a good idea? How do you solve this when porting to 64 bits?
    >>>

    >> There's a very obvious answer to that one. As a compiler-writer, youa
    >> re in a position to do it.

    >
    > I presume the solution you're suggesting is to make int 64 bits. How
    > does this help? strlen() still returns size_t, and if int and size_t
    > are both 64 bits, there will still be size_t values that cannot be
    > stored in an int.
    >

    Yes, but then you'd need an extremely long string to break the code, so the
    warning can be suppressed with some confidence that it won't cause a
    malfunction.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Aug 29, 2007
    #8
  9. jacob navia

    jacob navia Guest

    Keith Thompson wrote:
    > Why didn't you get the same warnings in 32-bit mode? If int and
    > size_t are both 32 bits, INT_MAX < SIZE_MAX, and there are values of
    > size_t that cannot be stored in an int. If the "narrowing conversion"
    > warning is based on the sizes of the type rather than the ranges, I'd
    > say you've just discovered a compiler bug.
    >


    2GB strings are the most you can get under the windows schema in 32 bits.

    > If you're getting hundreds of warnings, it's because you have hundreds
    > of instances of potential loss of information.
    >


    Yes, "*POTENTIALLY*" I could be missing all those strings longer
    than 4GB (!!!). But I do not care about those :)

    > Note that a conversion to a signed type of a value that doesn't fit in
    > that type yields an implementation-defined result (or, in C99, raises
    > an implementation-defined signal). In theory, the result could be
    > more than just a loss of information.
    >


    Only for strings >2GB Keith. Let's keep it realistic!

    > The problem is to distinguish cases where the conversion can't
    > actually overflow at execution times from the cases where it can.
    >
    > Sufficiently clever dataflow analysis in the compiler might eliminate
    > some of the errors. If, given
    > int s = strlen(str);
    > the compiler knows enough about how the value of str that it can be
    > sure it's no longer than INT_MAX bytes, it can eliminate the warning.
    > But I don't know if it's practical, or even possible to eliminate
    > enough of the warnings this way. Doing this in most cases is hard;
    > doing it in all cases might be equivalent to solving the halting
    > problem. (That latter is only a guess.)
    >
    > (Making int 64 bits won't solve the problem, since INT_MAX will still
    > be less than SIZE_MAX.)
    >
    > You can filter the compiler's output to eliminate warnings about
    > narrowing implicit conversions (or, if available, use a compiler
    > option to turn off that particular warning), but that could miss cases
    > that could actually overflow.
    >
    > In my opinion, the warnings are legitimate. The ideal solution is not
    > to suppress them, but to fix the code, assigning the result of
    > strlen() to a size_t rather than to an int. (Or I suppose you could
    > use a cast to shut up the compiler if you're *certain* the result can
    > never exceed INT_MAX, but that's not what I'd do.)
    >
    > By compiling the code in 64-bit mode, you've discovered a number of
    > dormant bugs in the code.
    >


    There isn't any string longer than a few K in this program!
    Of course is a potential bug, but it is practically impossible!
    jacob navia, Aug 29, 2007
    #9
  10. jacob navia

    jacob navia Guest

    Ben Pfaff wrote:
    > jacob navia <> writes:
    >
    >> I am trying to compile as much code in 64 bit mode as
    >> possible to test the 64 bit version of lcc-win.
    >>
    >> The problem appears now that size_t is now 64 bits.
    >>
    >> Fine. It has to be since there are objects that are more than 4GB
    >> long.
    >>
    >> The problem is, when you have in thousands of places
    >>
    >> int s;
    >>
    >> // ...
    >> s = strlen(str) ;
    >>
    >> Since strlen returns a size_t, we have a 64 bit result being
    >> assigned to a 32 bit int.

    >
    > I'd suggest fixing the code that does this to use size_t instead
    > of int. size_t is correct. int is, at best, an approximation to
    > correct. We've just had a pretty long thread with Malcolm McLean
    > discussing this very topic; perhaps you should refer to that
    > thread, if you're not already aware of it.


    The problem is that if I change those ints into size_t's they
    are unsigned, and they will produce problems when comparing them with
    signed quantities, making MORE modifications necessary in a cascade
    of modifications that would surely introduce bugs...

    I have *already* introduced (int)strlen(...) in many places...
    jacob navia, Aug 29, 2007
    #10
  11. jacob navia

    jacob navia Guest

    Malcolm McLean wrote:
    >
    > "jacob navia" <> wrote in message
    > news:46d5c46d$0$5108$...
    >> I am trying to compile as much code in 64 bit mode as
    >> possible to test the 64 bit version of lcc-win.
    >>
    >> The problem appears now that size_t is now 64 bits.
    >>
    >> Fine. It has to be since there are objects that are more than 4GB
    >> long.
    >>
    >> The problem is, when you have in thousands of places
    >>
    >> int s;
    >>
    >> // ...
    >> s = strlen(str) ;
    >>
    >> Since strlen returns a size_t, we have a 64 bit result being
    >> assigned to a 32 bit int.
    >>
    >> This can be correct, and in 99.9999999999999999999999999%
    >> of the cases the string will be smaller than 2GB...
    >>
    >> Now the problem:
    >>
    >> Since I warn each time a narrowing conversion is done (since
    >> that could loose data) I end up with hundreds of warnings each time
    >> a construct like int a = strlen(...) appears. This clutters
    >> everything, and important warnings go lost.
    >>
    >>
    >> I do not know how to get out of this problem. Maybe any of you has
    >> a good idea? How do you solve this when porting to 64 bits?
    >>

    > There's a very obvious answer to that one. As a compiler-writer, youa re
    > in a position to do it.
    >


    ???

    (Please excuse my stupidity by I do not see it...)
    jacob navia, Aug 29, 2007
    #11
  12. On Aug 29, 8:08 pm, jacob navia <> wrote:
    > I am trying to compile as much code in 64 bit mode as
    > possible to test the 64 bit version of lcc-win.
    >
    > The problem appears now that size_t is now 64 bits.
    >
    > Fine. It has to be since there are objects that are more than 4GB
    > long.
    >
    > The problem is, when you have in thousands of places
    >
    > int s;
    >
    > // ...
    > s = strlen(str) ;
    >
    > Since strlen returns a size_t, we have a 64 bit result being
    > assigned to a 32 bit int.
    >
    > This can be correct, and in 99.9999999999999999999999999%
    > of the cases the string will be smaller than 2GB...
    >
    > Now the problem:
    >
    > Since I warn each time a narrowing conversion is done (since
    > that could loose data) I end up with hundreds of warnings each time
    > a construct like int a = strlen(...) appears. This clutters
    > everything, and important warnings go lost.
    >
    > I do not know how to get out of this problem. Maybe any of you has
    > a good idea? How do you solve this when porting to 64 bits?


    So the compiler is giving a warning when a 64 bit value is assigned to
    a 32 bit variable, but not when a 32 bit unsigned value is assigned to
    a 32 bit signed variable.

    Well, just because you changed size_t to 64 bits doesn't make strings
    any longer. strlen ("hello") still returns 5 and it will fit into an
    int just as well as before. So you _could_, possibly as a compiler
    option, mark certain functions as returning small(ish) values that
    don't require a warning when stored in an int.

    But maybe you should look at it from the point of view of a developer
    who is switching from a 32 bit to a 64 bit compiler (or most likely
    wants to write code that runs fine on a 32 bit and a 64 bit system),
    and who _wants_ to fix problems. That programmer would _want_ the
    warning and change the variable from int to something else.

    Here is the approach that Apple takes: Define two typedefs, Int and
    Uint (they actually use different names, but that doesn't matter).
    These are used for almost all integer values. On a 32 bit system (32
    bit int/long/size_t) they are equal to int/unsigned int, on a 64 bit
    system (32 bit int, 64 bit long/size_t) they are equal to long/
    unsigned long. Your warning problem goes away. Different types are
    used on purpose so that if you mismatch int*/Int* or long*/Int* either
    the 32 bit or 64 bit version will give you a compiler error.

    Situations where you don't use these types: If you definitely need 64
    bit, use long long. If you want to save space, use char/short/int as
    suitable.
    christian.bau, Aug 29, 2007
    #12
  13. "jacob navia" <> wrote in message
    news:46d5d579$0$27386$...
    > Malcolm McLean wrote:
    >> There's a very obvious answer to that one. As a compiler-writer, youa re
    >> in a position to do it.
    >>

    >
    > ???
    >
    > (Please excuse my stupidity by I do not see it...)
    >

    The campaign for 64 bit ints T-shirts obviously didn't generate enough
    publicity. I still have a few left. XXL, one size fits all.

    There are some good reasons for not making int 64 bits on a 64 bit machine,
    which as a compiler-writer you will be well aware of. However typical
    computers are going to have 64 bits of main address space for a very long
    time to come, so it makes sense to get the language right now, and keep it
    that way for the forseeable future, and not allow decisions to be dominated
    by the need to maintain compatibility with legacy 32 bit libraries.


    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Aug 29, 2007
    #13
  14. On Wed, 29 Aug 2007 20:52:20 +0100, Malcolm McLean wrote:

    > "Ben Pfaff" <> wrote in message
    > news:...
    >> I'd suggest fixing the code that does this to use size_t instead
    >> of int. size_t is correct. int is, at best, an approximation to
    >> correct. We've just had a pretty long thread with Malcolm McLean
    >> discussing this very topic; perhaps you should refer to that
    >> thread, if you're not already aware of it.
    >>

    > Yup. As I said, if people would use size_t consistently for every single
    > calculation that ultimately ends up in an array index there wouldn't be such
    > a problem. The reality is that people won't, and lots of code doesn't.


    And lots of people do and lots of code does, and those people don't get
    those problems on that code.

    Which just goes to show, doing the right thing - using size_t - makes
    perfect sense, and ignoring the right thing - as you persist in doing -
    makes for problems.
    Kelsey Bjarnason, Aug 29, 2007
    #14
  15. jacob navia

    user923005 Guest

    On Aug 29, 12:08 pm, jacob navia <> wrote:
    > I am trying to compile as much code in 64 bit mode as
    > possible to test the 64 bit version of lcc-win.
    >
    > The problem appears now that size_t is now 64 bits.
    >
    > Fine. It has to be since there are objects that are more than 4GB
    > long.
    >
    > The problem is, when you have in thousands of places
    >
    > int s;
    >
    > // ...
    > s = strlen(str) ;
    >
    > Since strlen returns a size_t, we have a 64 bit result being
    > assigned to a 32 bit int.
    >
    > This can be correct, and in 99.9999999999999999999999999%
    > of the cases the string will be smaller than 2GB...
    >
    > Now the problem:
    >
    > Since I warn each time a narrowing conversion is done (since
    > that could loose data) I end up with hundreds of warnings each time
    > a construct like int a = strlen(...) appears. This clutters
    > everything, and important warnings go lost.
    >
    > I do not know how to get out of this problem. Maybe any of you has
    > a good idea? How do you solve this when porting to 64 bits?


    Make your default int 64 bits, and be done with it.
    Ought to be 64 bits on a 64 bit platform anyway.
    user923005, Aug 29, 2007
    #15
  16. jacob navia

    user923005 Guest

    On Aug 29, 12:51 pm, Keith Thompson <> wrote:
    > "Malcolm McLean" <> writes:
    > > "jacob navia" <> wrote in message
    > >news:46d5c46d$0$5108$...

    > [...]
    > >>I am trying to compile as much code in 64 bit mode as
    > >> possible to test the 64 bit version of lcc-win.

    >
    > >> The problem appears now that size_t is now 64 bits.

    >
    > [...]
    >
    >
    >
    >
    >
    > >> int s;

    >
    > >> // ...
    > >> s = strlen(str) ;

    >
    > >> Since strlen returns a size_t, we have a 64 bit result being
    > >> assigned to a 32 bit int.

    >
    > >> This can be correct, and in 99.9999999999999999999999999%
    > >> of the cases the string will be smaller than 2GB...

    >
    > >> Now the problem:

    >
    > >> Since I warn each time a narrowing conversion is done (since
    > >> that could loose data) I end up with hundreds of warnings each time
    > >> a construct like int a = strlen(...) appears. This clutters
    > >> everything, and important warnings go lost.

    >
    > >> I do not know how to get out of this problem. Maybe any of you has
    > >> a good idea? How do you solve this when porting to 64 bits?

    >
    > > There's a very obvious answer to that one. As a compiler-writer, youa
    > > re in a position to do it.

    >
    > I presume the solution you're suggesting is to make int 64 bits. How
    > does this help? strlen() still returns size_t, and if int and size_t
    > are both 64 bits, there will still be size_t values that cannot be
    > stored in an int.


    If strlen() returns a number bigger than 9,223,372,036,854,775,808
    then there are bigger fish to fry.
    Sure, Bill Gates supposedly said that nobody will ever need more than
    640K of RAM, and so someday it may be true that strings longer than 9
    quintillion bytes are common. But I guess it will be a minor problem
    until he can get around to fully correcting the code the right way by
    assigning size_t values to the return from strlen() and other things
    that return a size_t.
    user923005, Aug 29, 2007
    #16
  17. In article <46d5c46d$0$5108$>,
    jacob navia <> wrote:

    > s = strlen(str) ;
    >
    >Since strlen returns a size_t, we have a 64 bit result being
    >assigned to a 32 bit int.
    >
    >This can be correct, and in 99.9999999999999999999999999%
    >of the cases the string will be smaller than 2GB...


    Clearly with strlen() the chance of it being an error is negligible.
    And I think this is true other size_t->int assignments. For example,
    int s = sizeof(whatever) is almost never a problem.

    Ideally, I would suggest not generating a warning unless some option
    is set for it. (There should always be a "maximally paranoid" option
    to help track down obscure errors.) But that only applies to
    size_t->int assignments. Other 64->32 assignments may be more likely to be
    in error. At the point you generate the warning, can you still tell
    that it's a size_t rather than some other 64-bit int type?

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Aug 29, 2007
    #17
  18. "Malcolm McLean" <> writes:
    > "Keith Thompson" <> wrote in message
    > news:...
    >> "Malcolm McLean" <> writes:

    [...]
    >>> There's a very obvious answer to that one. As a compiler-writer, youa
    >>> re in a position to do it.

    >>
    >> I presume the solution you're suggesting is to make int 64 bits. How
    >> does this help? strlen() still returns size_t, and if int and size_t
    >> are both 64 bits, there will still be size_t values that cannot be
    >> stored in an int.
    >>

    > Yes, but then you'd need an extremely long string to break the code,
    > so the warning can be suppressed with some confidence that it won't
    > cause a malfunction.


    That's assuming you're able to suppress the warning for 64-bit
    unsigned to 64-bit signed conversions without supressing warnings for,
    say, 8-bit unsigned to 8-bit signed conversions. I don't know of any
    compiler that allow that kind of find-grained control.

    It's better to fix the code. It's even better to write it correctly
    in the first place.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 29, 2007
    #18
  19. In article <>,
    user923005 <> wrote:
    >Make your default int 64 bits, and be done with it.
    >Ought to be 64 bits on a 64 bit platform anyway.


    A compiler for an existing operating system needs to fit in with the
    system's libraries, so he may not have that choice.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Aug 29, 2007
    #19
  20. In article <>,
    Keith Thompson <> wrote:

    >It's better to fix the code. It's even better to write it correctly
    >in the first place.


    But int s = sizeof(char *) is not broken, even though sizeof() returns
    a size_t.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Aug 29, 2007
    #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. Howard Hinnant

    Re: size_t ... standards

    Howard Hinnant, Jun 29, 2003, in forum: C++
    Replies:
    5
    Views:
    3,561
    Jim Fischer
    Jun 30, 2003
  2. Howard Hinnant

    Re: size_t ... standards

    Howard Hinnant, Jun 29, 2003, in forum: C++
    Replies:
    0
    Views:
    836
    Howard Hinnant
    Jun 29, 2003
  3. Chris \( Val \)

    Re: for(size_t a=begin();a!=end();++a){}

    Chris \( Val \), Jul 13, 2003, in forum: C++
    Replies:
    2
    Views:
    349
    John Harrison
    Jul 14, 2003
  4. Alex Vinokur
    Replies:
    9
    Views:
    785
    James Kanze
    Oct 13, 2008
  5. Alex Vinokur
    Replies:
    1
    Views:
    574
Loading...

Share This Page