First attempt to use strtoll: What am I doing wrong?

Discussion in 'C Programming' started by robert maas, see http://tinyurl.com/uh3t, Feb 12, 2007.

  1. Here's the source:
    #include <stdio.h>
    #include <errno.h>
    main () {
    char* str = "9999999999";
    long long int llin; char* endptr; /* Set by strtoll */
    int nch;
    errno = 0;
    llin = strtoll(str, &endptr, 10);
    printf("errno=%d\n", errno);
    nch = endptr-str;
    printf("It processed %d digits.\n", nch);
    printf("N=%lld\n", llin);
    }

    Here's the output.
    errno=0
    It processed 10 digits.
    N=1410065407

    I expected that last line to print the correct long long value, all 9's.
    robert maas, see http://tinyurl.com/uh3t, Feb 12, 2007
    #1
    1. Advertising

  2. robert maas, see http://tinyurl.com/uh3t

    Jack Klein Guest

    On Sun, 11 Feb 2007 20:45:23 -0800, (robert maas,
    see http://tinyurl.com/uh3t) wrote in comp.lang.c:

    > Here's the source:
    > #include <stdio.h>
    > #include <errno.h>
    > main () {


    Make that:

    int main()

    ....or even better:

    int main(void)

    The current C standard, the one that includes the type "long long",
    has also outlawed implicit int.

    > char* str = "9999999999";
    > long long int llin; char* endptr; /* Set by strtoll */
    > int nch;
    > errno = 0;
    > llin = strtoll(str, &endptr, 10);
    > printf("errno=%d\n", errno);
    > nch = endptr-str;
    > printf("It processed %d digits.\n", nch);
    > printf("N=%lld\n", llin);
    > }
    >
    > Here's the output.
    > errno=0
    > It processed 10 digits.
    > N=1410065407
    >
    > I expected that last line to print the correct long long value, all 9's.


    What does your documentation (C book, compiler on-line help, man
    pages, whatever) have to say about strtoll()?

    OK, I'll give you a hint: where does your documentation say that the
    prototype for strtoll() lives?

    Under the current C standard, it is invalid to call a function without
    a declaration in scope. Under earlier C standards, it is undefined
    behavior to call a function without a declaration in scope if the
    function returns anything other than an int.

    And finally, what does your documentation say about invoking your
    compiler in a way that it will warn you when you call a function
    without a prototype in scope?

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Feb 12, 2007
    #2
    1. Advertising

  3. robert maas, see http://tinyurl.com/uh3t wrote:
    > Here's the source:
    > #include <stdio.h>
    > #include <errno.h>
    > main () {
    > char* str = "9999999999";
    > long long int llin; char* endptr; /* Set by strtoll */
    > int nch;
    > errno = 0;
    > llin = strtoll(str, &endptr, 10);
    > printf("errno=%d\n", errno);
    > nch = endptr-str;
    > printf("It processed %d digits.\n", nch);
    > printf("N=%lld\n", llin);
    > }
    >
    > Here's the output.
    > errno=0
    > It processed 10 digits.
    > N=1410065407
    >
    > I expected that last line to print the correct long long value, all 9's.


    And I would expect you to use decent settings for diagnostics.
    There are two lines added below and one changed. Notice the output.

    #include <stdio.h>
    #include <errno.h>
    #include <stdlib.h> /* mha: added for strtoll */

    int main(void)
    {
    char *str = "9999999999";
    long long int llin;
    char *endptr; /* Set by strtoll */
    int nch;
    errno = 0;
    llin = strtoll(str, &endptr, 10);
    printf("errno=%d\n", errno);
    nch = endptr - str;
    printf("It processed %d digits.\n", nch);
    printf("N=%lld\n", llin);
    return 0;
    }

    [output]
    errno=0
    It processed 10 digits.
    N=9999999999
    Martin Ambuhl, Feb 12, 2007
    #3
  4. > From: Jack Klein <>
    > What does your documentation (C book, compiler on-line help, man
    > pages, whatever) have to say about strtoll()?
    > OK, I'll give you a hint: where does your documentation say that the
    > prototype for strtoll() lives?


    Well, it's my impression that the header file is supposed to tell
    the compiler what the prototype is, so it can compile correct
    linkage, and also tell the loader where to find the actual module
    to load, so the function will be defined at runtime, so the loader
    won't bomb with unresolved symbol. So I assumed if the loader
    doesn't complain that it can't find the actual function, then the
    correct header file must have been included.

    But I looked in the online doc again, and I see it says:
    #include <stdlib.h> ; #include <limits.h>
    So I put in that first one, didn't bother with limits, and that
    fixed the problem. Thanks!!

    > And finally, what does your documentation say about invoking your
    > compiler in a way that it will warn you when you call a function
    > without a prototype in scope?


    Well I took the stdlib include back out, and tried
    -Wmissing-prototypes, but that complained about the three functions
    I'm defining, and didn't complain about strtoll.
    Then I tried -Wmissing-declarations, which likewise complained
    about my own functions but didn't mention strtoll.
    Then I tried -Wimplicit-function-declaration, and it said:
    tryll.c: In function `tryParseLliTalk':
    tryll.c:52: warning: implicit declaration of function `strtoll'
    Aha!! Thanks again.

    Hmm, I wonder if -Wmain checks for those other things you
    mentionned ... nope. -pedantic ? Nope, just complains repeatedly:
    warning: ANSI C does not support `long long'

    -Wall gives a whole bunch (new expanded version of program I
    haven't yet posted):

    tryll.c: In function `printflld':
    void printflld(long long int n) {

    tryll.c:5: warning: int format, different type arg (arg 2)
    if ((n>=0) && (n<=9)) printf("%d", n);
    (oops, that should be)
    if ((n>=0) && (n<=9)) printf("%lld", n);

    tryll.c:8: warning: int format, different type arg (arg 2)
    printf("%d", n%10);
    (OK, I can cast that safely:)
    printf("%d", (int)(n%10));
    (Yeah, I almost made the mistake of omitting parens around whole n%10, phew!)

    tryll.c: In function `tryParseLliTalk':
    tryll.c:52: warning: implicit declaration of function `strtoll'
    (yeah, putting the include back in)

    tryll.c: At top level:
    tryll.c:66: warning: return-type defaults to `int'
    main () {
    OK, there we go, what you said earlier:
    int main (void) {

    tryll.c: In function `main':
    tryll.c:77: warning: control reaches end of non-void function
    OK, I'll do this:
    return(0);

    gcc tryll.c -Wall
    (No warnings!)

    Anyway, here's part of what I was going to post before I saw your
    reply but this is now moot:

    Update from previous posting:
    I saw this note:
    <http://gcc.gnu.org/ml/gcc-prs/2002-05/msg00695.html>
    wherein there's alleged to be a bug in the printf %lld format
    directive, so maybe I'm not doing anything wrong with strtoll, it's
    getting the correct value parsed, but then the printf %lld is
    showing garbage. So I wrote my own (recursive) decimal-print
    function to see what value is *really* in the long long int
    variable assigned from strtoll. Well I get the same printout as
    sprint does, so the %lld format directive isn't the problem. I'm
    really getting a bad result from strtoll. So then I wrote my own
    substitute for strtoll, and *now* I'm getting the correct long long
    int value, which prints correctly via both the %lld directive and
    my own %lld substitute.
    robert maas, see http://tinyurl.com/uh3t, Feb 12, 2007
    #4
  5. robert maas, see http://tinyurl.com/uh3t

    Barry Guest

    <OT> Re: First attempt to use strtoll: What am I doing wrong?

    "robert maas, see http://tinyurl.com/uh3t" <> wrote in
    message news:...
    > > From: Jack Klein <>
    > > What does your documentation (C book, compiler on-line help, man
    > > pages, whatever) have to say about strtoll()?
    > > OK, I'll give you a hint: where does your documentation say that the
    > > prototype for strtoll() lives?

    >
    > Well, it's my impression that the header file is supposed to tell
    > the compiler what the prototype is, so it can compile correct
    > linkage, and also tell the loader where to find the actual module
    > to load, so the function will be defined at runtime, so the loader
    > won't bomb with unresolved symbol. So I assumed if the loader
    > doesn't complain that it can't find the actual function, then the
    > correct header file must have been included.
    >
    > But I looked in the online doc again, and I see it says:
    > #include <stdlib.h> ; #include <limits.h>
    > So I put in that first one, didn't bother with limits, and that
    > fixed the problem. Thanks!!
    >
    > > And finally, what does your documentation say about invoking your
    > > compiler in a way that it will warn you when you call a function
    > > without a prototype in scope?

    >
    > Well I took the stdlib include back out, and tried
    > -Wmissing-prototypes, but that complained about the three functions
    > I'm defining, and didn't complain about strtoll.
    > Then I tried -Wmissing-declarations, which likewise complained
    > about my own functions but didn't mention strtoll.
    > Then I tried -Wimplicit-function-declaration, and it said:
    > tryll.c: In function `tryParseLliTalk':
    > tryll.c:52: warning: implicit declaration of function `strtoll'
    > Aha!! Thanks again.
    >
    > Hmm, I wonder if -Wmain checks for those other things you
    > mentionned ... nope. -pedantic ? Nope, just complains repeatedly:
    > warning: ANSI C does not support `long long'
    >

    <OT>
    I believe if you check -pedantic again, it does indeed complain.
    Additionally you can stop it from complaining about long long
    by telling it which stardard to complain about i.e. std=c99.
    </OT>
    Barry, Feb 12, 2007
    #5
  6. On Sun, 11 Feb 2007 23:59:09 -0800, in comp.lang.c ,
    (robert maas, see http://tinyurl.com/uh3t) wrote:

    >> From: Jack Klein <>
    >> What does your documentation (C book, compiler on-line help, man
    >> pages, whatever) have to say about strtoll()?
    >> OK, I'll give you a hint: where does your documentation say that the
    >> prototype for strtoll() lives?

    >
    >Well, it's my impression that the header file is supposed to tell
    >the compiler what the prototype is,


    Typically the header /contains/ the prototype.

    >so it can compile correct
    >linkage, and also tell the loader where to find the actual module
    >to load,


    no, thats generally the job of the user (via commandline args,
    environment variables etc). The header just tells the compiler what
    the function looks like.

    >so the function will be defined at runtime, so the loader
    >won't bomb with unresolved symbol. So I assumed if the loader
    >doesn't complain that it can't find the actual function, then the
    >correct header file must have been included.


    No, it just means your programme compiled. How your envrionment
    handles programme loading isn't defined by the compiler.

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Feb 12, 2007
    #6
  7. robert maas wrote:
    >... it's my impression that the header file is supposed to tell
    >the compiler what the prototype is, so it can compile correct
    >linkage, and also tell the loader where to find the actual module
    >to load, so the function will be defined at runtime, so the loader
    >won't bomb with unresolved symbol. So I assumed if the loader
    >doesn't complain that it can't find the actual function, then the
    >correct header file must have been included.


    Although it would be possible for a C implementation to work that way,
    most do not.
    In the general case, including the header only provides the compiler
    with information on the function's parameters and return type, so that
    it may generate correct code.
    The linker/loader receives a list of the libraries that should be
    included via a totally separated mechanism, including a small list of
    "default" libraries.

    If in your case the linker did not complain about missing symbols, it
    is only because the functions in question were in one of libraries
    used by default.

    Roberto Waltman

    [ Please reply to the group,
    return address is invalid ]
    Roberto Waltman, Feb 12, 2007
    #7
  8. (robert maas, see http://tinyurl.com/uh3t) writes:
    [...]
    > Update from previous posting:
    > I saw this note:
    > <http://gcc.gnu.org/ml/gcc-prs/2002-05/msg00695.html>
    > wherein there's alleged to be a bug in the printf %lld format
    > directive, so maybe I'm not doing anything wrong with strtoll, it's
    > getting the correct value parsed, but then the printf %lld is
    > showing garbage. So I wrote my own (recursive) decimal-print
    > function to see what value is *really* in the long long int
    > variable assigned from strtoll. Well I get the same printout as
    > sprint does, so the %lld format directive isn't the problem. I'm
    > really getting a bad result from strtoll. So then I wrote my own
    > substitute for strtoll, and *now* I'm getting the correct long long
    > int value, which prints correctly via both the %lld directive and
    > my own %lld substitute.


    The strtoll() function is new in C99 (obviously, since long long
    didn't exist prior to C99). It's possible that your library and your
    headers are out of synch; specifically that your library implements
    the strtoll() function, but your <stdlib.h> header doesn't provide a
    prototype for it.

    Crank up your compiler's warning levels and see if you get a warning
    about a missing declaration for strtoll() even if you've include
    <stdlib.h>. Write a one-line C source file:
    #include <stdlib.h>
    and, if your compiler supports it, examine the preprocessor's output
    <OT>gcc -E</OT>, and see if there's a prototype for strtol() but not
    for strtoll().

    If this is the problem, a workaround is to provide your own prototype
    for strtoll():

    unsigned long long int strtoull(
    const char * restrict nptr,
    char ** restrict endptr,
    int base);

    But this might cause problems if your implementation *does* properly
    support strtoll().

    --
    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.
    Keith Thompson, Feb 12, 2007
    #8
  9. robert maas, see http://tinyurl.com/uh3t

    Joe Wright Guest

    robert maas, see http://tinyurl.com/uh3t wrote:
    >> From: Jack Klein <>
    >> What does your documentation (C book, compiler on-line help, man
    >> pages, whatever) have to say about strtoll()?
    >> OK, I'll give you a hint: where does your documentation say that the
    >> prototype for strtoll() lives?

    >
    > Well, it's my impression that the header file is supposed to tell
    > the compiler what the prototype is, so it can compile correct
    > linkage, and also tell the loader where to find the actual module
    > to load, so the function will be defined at runtime, so the loader
    > won't bomb with unresolved symbol. So I assumed if the loader
    > doesn't complain that it can't find the actual function, then the
    > correct header file must have been included.
    >
    > But I looked in the online doc again, and I see it says:
    > #include <stdlib.h> ; #include <limits.h>
    > So I put in that first one, didn't bother with limits, and that
    > fixed the problem. Thanks!!
    >
    >> And finally, what does your documentation say about invoking your
    >> compiler in a way that it will warn you when you call a function
    >> without a prototype in scope?

    >
    > Well I took the stdlib include back out, and tried
    > -Wmissing-prototypes, but that complained about the three functions
    > I'm defining, and didn't complain about strtoll.
    > Then I tried -Wmissing-declarations, which likewise complained
    > about my own functions but didn't mention strtoll.
    > Then I tried -Wimplicit-function-declaration, and it said:
    > tryll.c: In function `tryParseLliTalk':
    > tryll.c:52: warning: implicit declaration of function `strtoll'
    > Aha!! Thanks again.
    >
    > Hmm, I wonder if -Wmain checks for those other things you
    > mentionned ... nope. -pedantic ? Nope, just complains repeatedly:
    > warning: ANSI C does not support `long long'
    >
    > -Wall gives a whole bunch (new expanded version of program I
    > haven't yet posted):
    >
    > tryll.c: In function `printflld':
    > void printflld(long long int n) {
    >
    > tryll.c:5: warning: int format, different type arg (arg 2)
    > if ((n>=0) && (n<=9)) printf("%d", n);
    > (oops, that should be)
    > if ((n>=0) && (n<=9)) printf("%lld", n);
    >
    > tryll.c:8: warning: int format, different type arg (arg 2)
    > printf("%d", n%10);
    > (OK, I can cast that safely:)
    > printf("%d", (int)(n%10));
    > (Yeah, I almost made the mistake of omitting parens around whole n%10, phew!)
    >
    > tryll.c: In function `tryParseLliTalk':
    > tryll.c:52: warning: implicit declaration of function `strtoll'
    > (yeah, putting the include back in)
    >
    > tryll.c: At top level:
    > tryll.c:66: warning: return-type defaults to `int'
    > main () {
    > OK, there we go, what you said earlier:
    > int main (void) {
    >
    > tryll.c: In function `main':
    > tryll.c:77: warning: control reaches end of non-void function
    > OK, I'll do this:
    > return(0);
    >
    > gcc tryll.c -Wall
    > (No warnings!)
    >
    > Anyway, here's part of what I was going to post before I saw your
    > reply but this is now moot:
    >
    > Update from previous posting:
    > I saw this note:
    > <http://gcc.gnu.org/ml/gcc-prs/2002-05/msg00695.html>
    > wherein there's alleged to be a bug in the printf %lld format
    > directive, so maybe I'm not doing anything wrong with strtoll, it's
    > getting the correct value parsed, but then the printf %lld is
    > showing garbage. So I wrote my own (recursive) decimal-print
    > function to see what value is *really* in the long long int
    > variable assigned from strtoll. Well I get the same printout as
    > sprint does, so the %lld format directive isn't the problem. I'm
    > really getting a bad result from strtoll. So then I wrote my own
    > substitute for strtoll, and *now* I'm getting the correct long long
    > int value, which prints correctly via both the %lld directive and
    > my own %lld substitute.


    Have a look..

    #include <stdio.h>
    #include <stdlib.h>
    #include <errno.h>

    int main(void) {
    char *str = "9999999999";
    long long int llin;
    char *endptr; /* Set by strtoll */
    int nch;
    errno = 0;
    llin = strtoll(str, &endptr, 10);
    printf("errno=%d\n", errno);
    nch = endptr - str;
    printf("It processed %d digits.\n", nch);
    printf("N=%lld\n", llin);
    return 0;
    }

    ...which gives me..

    errno=0
    It processed 10 digits.
    N=9999999999

    There's not much difference between yours and mine. What is it? :)

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Feb 13, 2007
    #9
  10. > From: Joe Wright <>
    > Have a look..

    (snipped, refer to <>)
    > There's not much difference between yours and mine. What is it? :)


    My *current* version (last edited Feb 11 23:55 PST) looks like this:

    #include <stdio.h>
    #include <errno.h>
    #include <stdlib.h>

    void printflld(long long int n) {
    if ((n>=0) && (n<=9)) printf("%lld", n);
    else if (n>9) {
    printflld(n/10);
    printf("%d", (int)(n%10));
    } else {
    long long int nneg;
    printf("-");
    nneg = -n;
    if (nneg>0) { /* If n was negative but not most-negative possible. */
    printflld(nneg);
    } else printf("9223372036854775808"); /* N = most negative long long int */
    }
    }

    /* Requires snum to immediately start with minus sign or first digit.
    Doesn't handle leading whitespace nor plus sign. Treats empty string
    as zero. Doesn't handle any base except decimal. Doesn't report end
    of digits parsed via second parameter. Otherwise should behave as strtoll
    was advertised. It *does* set errno in case of overflow! */
    long long int mystrtoll(char* snum) {
    int sign = 1;
    long long int val = 0;
    char* ptr = snum;
    if (*ptr == '-') {
    sign = -1;
    ptr++;
    }
    while (1) {
    char ch = *ptr;
    if (('0' <= ch) && (ch <= '9')) {
    int digval = (ch-'0')*sign;
    val = val*10 + digval;
    if (digval != val%10) {
    errno = ERANGE;
    return(-1);
    }
    ptr++;
    } else break;
    }
    return(val);
    }

    void tryParseLliTalk(char* str) {
    long long int llin; char* endptr; /* Set by strtoll */
    int nch;
    printf("\n** String is [%s]\n", str);
    errno = 0;
    llin = strtoll(str, &endptr, 10);
    printf("errno=%d\n", errno);
    nch = endptr-str;
    printf("It processed %d digits.\n", nch);
    printf("N = %lld = ", llin);
    printflld(llin); printf("\n");
    errno = 0;
    llin = mystrtoll(str);
    printf("errno=%d\n", errno);
    printf("N = %lld = ", llin);
    printflld(llin); printf("\n");
    printf("String is still [%s]\n", str);
    }

    int main (void) {
    tryParseLliTalk("999999999");
    tryParseLliTalk("-999999999");
    tryParseLliTalk("9999999999");
    tryParseLliTalk("-9999999999");
    tryParseLliTalk("2147483647");
    tryParseLliTalk("2147483648");
    tryParseLliTalk("-2147483648");
    tryParseLliTalk("9223372036854775807");
    tryParseLliTalk("9223372036854775808");
    tryParseLliTalk("-9223372036854775808");
    return(0);
    }

    Presumably you're trying to offer corrections to the very first
    version I posted. So I went back to my backup copy of that, and
    used Compare Windows (feature of McSink), and found these
    differences:

    Your version has:
    #include <stdlib.h>
    but mine already got that a few days ago due to somebody else
    giving me the clue before you.

    Yours has return type int and args void on main, which mine also
    got a day or two ago due to somebody else giving me a clue to try
    -Wall.

    Yours is indented 7 spaces instead of only 2 spaces for the body of
    main, so I'll have to reformat yours before I can compare the rest
    with mine. (Why do you deliberately make things hard for newbies?)

    You've moved the * in the declaration for str, which I already know
    is totally irrelevant, so why waste my time?

    You've also split the two items set by strtoll, making that comment
    a half truth which is a lie. I'd rather violate one-stmt-per-line
    police so that I can have a single comment that refers to two
    declarations on the same line, than what you did of splitting to
    make a half-truth lie, or duplicating the comment onto both lines.

    You've inserted spaces around the subtraction operator between two
    pointers, as if that was a fucking important thing to do to make or
    break a program. Why can't you stick to what's important?

    You included "return 0;", which I already did in response to -Wall
    in clue from the person a few days ago already. But what's the
    matter with you, you're a perl programmer at heart, love to omit
    the parens around arguments to functions, which works *only* when
    there's exactly one argument? I prefer always use parens so the
    same syntax works uniformly regardless of number of arguments.

    So anyway, the only *important* thing you changed was including the
    header for stdlib, so that the long long type of return value from
    strtoll would be declared and cause correct linkage to be compiled.
    (GNU C compiler is too dumb to keep the presumed type around at
    linkage time and check against actual type of library functions, so
    that a diagnostic could be reported at that time, such as "Error:
    Linkage for return value from strtoll assumed type int, but library
    function uses long long int instead, making the linkage
    incorrect.")
    robert maas, see http://tinyurl.com/uh3t, Feb 14, 2007
    #10
  11. (robert maas, see http://tinyurl.com/uh3t) writes:
    [...]
    > Yours is indented 7 spaces instead of only 2 spaces for the body of
    > main, so I'll have to reformat yours before I can compare the rest
    > with mine. (Why do you deliberately make things hard for newbies?)


    It probably didn't occur to him that changing the indentation would
    cause problems. With the tool set I use, for example, it's easy to
    compare two text files while ignoring whitespace.

    [...]

    > You included "return 0;", which I already did in response to -Wall
    > in clue from the person a few days ago already. But what's the
    > matter with you, you're a perl programmer at heart, love to omit
    > the parens around arguments to functions, which works *only* when
    > there's exactly one argument? I prefer always use parens so the
    > same syntax works uniformly regardless of number of arguments.


    You appear to have several serious misunderstandings here.

    A return statement is not a function call; it is its own special kind
    of statement with its own syntax. You can legally use "return(0);"
    rather than "return 0;", and some programmers do so, but it's not
    necessary. The parentheses are not part of the syntax of the return
    statement; they're part of the expression. In other words, the
    parentheses in
    return(0);
    serve exactly the same role as the parentheses in
    x = (0);
    They're unnecessary in both cases. Personally, I prefer *not* to use
    extraneous parentheses on a return statement; they make it look like a
    function call, but it isn't one. You can use the parentheses if you
    like, of course, but people are likely to comment on it.

    A function call, on the other hand, *always* requires parentheses,
    regardless of the number of arguments. Even if there are no
    arguments, you still need empty parentheses: "func()". (And note that
    "return ();" is a syntax error.)

    I won't comment on whether Joe Wright *should* have made these
    stylistic changes to your program, but in this case it's a good thing
    he did so and (accidentally) raised this issue.

    [...]

    --
    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.
    Keith Thompson, Feb 14, 2007
    #11
  12. > From: Keith Thompson <>
    > It probably didn't occur to him that changing the indentation
    > would cause problems.


    It's not a problem, just a fucking nuisance that he *said* there was
    only one little change but in fact there were:
    - header file inclusion
    - return type on main
    - void args to main
    - indentation
    - * moved in declaration of pointer variable
    - two declarations on one line, with comment that applies to both,
    split so the comment incorrectly seems to apply to just one of
    the two declarations
    - spaces around subtraction operator
    - return 0; statement at end of main
    That's eight (8) completely different changes he made, and I'm
    supposed to guess which of them he's referring to as:
    "There's not much difference between yours and mine. What is it?"

    Which of the 8 changes is "it"???
    I should cross-post a copy of his posting to alt.usage.english and
    ask the folks there what the referent for "it" is supposed to be.

    > With the tool set I use, for example, it's easy to compare two
    > text files while ignoring whitespace.


    Does your toolset work on Macintosh System 7.5.5? If not, I can't
    use it here, and your mention of it is a bit of snobbery, nyah
    nyah, I have more money to buy more toolsets than you have, so nyah
    nyah I'm a better person than you are because of all the money I
    have. I'm stuck with what I have already, or what I can download
    for free that runs on my Mac.

    Yes, I could upload all the files to Unix and do the comparison
    there instead of on my Mac. That would be a pain, not worth the
    trouble. Easier to reformat what I have here on the Mac so a direct
    character-by-character Compare Windows will tell me what I need to
    know. But I wouldn't have had to do either if the other poster
    hadn't changed the indentation, especially with all the *other* red
    herrings he threw in to try to distract me. The indentation was the
    least of my problems trying to guess which of the *other* seven
    changes he was talking about.

    > A return statement is not a function call; it is its own special
    > kind of statement with its own syntax.


    Ah, thanks for the "heads up". I can't find return listed in the
    operator precedence chart. How does it interreact with other
    operators? For example, can you say:
    char* askMult5(int x) {
    return x%5==0 ? "multiple of 5" : "leaves remainder";
    }
    and get the intended effect?

    > San Diego Supercomputer Center


    Ah ha, no wonder you display snobbery about the powerful tools you
    have that I don't have. All I have here is a 68030 CPU. Your
    supercomputer could probably factor a 120-digit number, product of
    two 60-digit primes, in half a second. It probably has more than 8
    megabytes of RAM too! :)
    robert maas, see http://tinyurl.com/uh3t, Feb 14, 2007
    #12
  13. robert maas, see http://tinyurl.com/uh3t

    Ben Pfaff Guest

    (robert maas, see http://tinyurl.com/uh3t) writes:

    >> From: Keith Thompson <>
    >> With the tool set I use, for example, it's easy to compare two
    >> text files while ignoring whitespace.

    >
    > Does your toolset work on Macintosh System 7.5.5? If not, I can't
    > use it here, and your mention of it is a bit of snobbery, nyah
    > nyah, I have more money to buy more toolsets than you have, so nyah
    > nyah I'm a better person than you are because of all the money I
    > have. I'm stuck with what I have already, or what I can download
    > for free that runs on my Mac.


    GNU diff can do what Keith's tool can do (and it may be Keith's
    tool). It is free.

    >> A return statement is not a function call; it is its own special
    >> kind of statement with its own syntax.

    >
    > Ah, thanks for the "heads up". I can't find return listed in the
    > operator precedence chart. How does it interreact with other
    > operators? [...]


    Do you understand that a statement is different from an operator?
    return is a statement, not an operator.
    --
    "I hope, some day, to learn to read.
    It seems to be even harder than writing."
    --Richard Heathfield
    Ben Pfaff, Feb 14, 2007
    #13
  14. (robert maas, see http://tinyurl.com/uh3t) writes:
    >> From: Keith Thompson <>

    [...]
    >> With the tool set I use, for example, it's easy to compare two
    >> text files while ignoring whitespace.

    >
    > Does your toolset work on Macintosh System 7.5.5? If not, I can't
    > use it here, and your mention of it is a bit of snobbery, nyah
    > nyah, I have more money to buy more toolsets than you have, so nyah
    > nyah I'm a better person than you are because of all the money I
    > have. I'm stuck with what I have already, or what I can download
    > for free that runs on my Mac.


    I don't know whether it works on your system or not, but I wouldn't be
    at all surprised if it does. I don't know what tools are available on
    different systems to compare source files. My point -- my *only*
    point -- was that Joe Wright may well not have been aware of the
    limitations of the tools you're using. It just might not have
    occurred to him that changing the indentation would cause problems for
    you. It was most likely a minor innocent mistake on his part. By
    asking "Why do you deliberately make things hard for newbies?", you
    ignored that possibility and assumed malice where none was evident.

    The tool I use is GNU diff. It's free. Your assumption of snobbery
    is baseless and insulting.

    [...]

    >> A return statement is not a function call; it is its own special
    >> kind of statement with its own syntax.

    >
    > Ah, thanks for the "heads up". I can't find return listed in the
    > operator precedence chart. How does it interreact with other
    > operators? For example, can you say:
    > char* askMult5(int x) {
    > return x%5==0 ? "multiple of 5" : "leaves remainder";
    > }
    > and get the intended effect?


    "return" is neither a function nor an operator. It's a statement.
    The syntax for a return statement is either
    return;
    or
    return <expression>;
    Any decent C reference should tell you this. Do you own a copy of
    K&R2?

    >> San Diego Supercomputer Center

    >
    > Ah ha, no wonder you display snobbery about the powerful tools you
    > have that I don't have. All I have here is a 68030 CPU. Your
    > supercomputer could probably factor a 120-digit number, product of
    > two 60-digit primes, in half a second. It probably has more than 8
    > megabytes of RAM too! :)


    Somebody gave you a modified (and no doubt improved) version of the
    code you posted. He may or may not have taken into account any
    possible environmental limitations with which you're burdened, and he
    may have misstated the extent of the changes, but you can still learn
    something from it if you care to.

    Or you can just continue whining.

    --
    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.
    Keith Thompson, Feb 14, 2007
    #14
  15. robert maas, see http://tinyurl.com/uh3t

    santosh Guest

    robert maas, see http://tinyurl.com/uh3t wrote:
    > > From: Keith Thompson <>


    <snip>

    > > With the tool set I use, for example, it's easy to compare two
    > > text files while ignoring whitespace.

    >
    > Does your toolset work on Macintosh System 7.5.5? If not, I can't
    > use it here, and your mention of it is a bit of snobbery, nyah
    > nyah, I have more money to buy more toolsets than you have, so nyah
    > nyah I'm a better person than you are because of all the money I
    > have. I'm stuck with what I have already, or what I can download
    > for free that runs on my Mac.


    I think most file compare utilities ignore whitespace, or have a
    command line switch that instructs the same.

    > Yes, I could upload all the files to Unix and do the comparison
    > there instead of on my Mac. That would be a pain, not worth the
    > trouble. Easier to reformat what I have here on the Mac so a direct
    > character-by-character Compare Windows will tell me what I need to
    > know. But I wouldn't have had to do either if the other poster
    > hadn't changed the indentation, especially with all the *other* red
    > herrings he threw in to try to distract me. The indentation was the
    > least of my problems trying to guess which of the *other* seven
    > changes he was talking about.
    >
    > > A return statement is not a function call; it is its own special
    > > kind of statement with its own syntax.

    >
    > Ah, thanks for the "heads up". I can't find return listed in the
    > operator precedence chart. How does it interreact with other
    > operators? For example, can you say:
    > char* askMult5(int x) {
    > return x%5==0 ? "multiple of 5" : "leaves remainder";
    > }
    > and get the intended effect?


    return is not an operator. It's a statement. The accompanying
    expression is evaluated according to the rules of C and the resolved
    value is returned by the statement.

    If you get the expression right, then the return statement will do
    what you want. In the snippet given above, you're returning a value of
    type pointer to char that points to a non-existant object.
    santosh, Feb 14, 2007
    #15
  16. In article <> (robert maas, see http://tinyurl.com/uh3t) writes:
    > > From: Keith Thompson <>

    ....
    > > A return statement is not a function call; it is its own special
    > > kind of statement with its own syntax.

    >
    > Ah, thanks for the "heads up". I can't find return listed in the
    > operator precedence chart. How does it interreact with other
    > operators?


    It is also not an operator. How can it be either a function or an operator
    when the statement:
    return;
    is allowed?

    > For example, can you say:
    > char* askMult5(int x) {
    > return x%5==0 ? "multiple of 5" : "leaves remainder";
    > }
    > and get the intended effect?


    Of course.
    --
    dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
    home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
    Dik T. Winter, Feb 16, 2007
    #16
    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. Wes Harrison
    Replies:
    2
    Views:
    503
    Wes Harrison
    Jan 12, 2005
  2. Andrea Fino

    a first attempt

    Andrea Fino, Apr 24, 2004, in forum: HTML
    Replies:
    0
    Views:
    426
    Andrea Fino
    Apr 24, 2004
  3. The White Lady

    first attempt at webpage

    The White Lady, May 13, 2004, in forum: HTML
    Replies:
    15
    Views:
    644
    Mark Parnell
    May 18, 2004
  4. GMI
    Replies:
    3
    Views:
    502
    Tad McClellan
    Jun 19, 2005
  5. Tad J McClellan
    Replies:
    1
    Views:
    105
    Ted Byers
    Oct 22, 2008
Loading...

Share This Page