float pointers

Discussion in 'C Programming' started by ehabaziz2001@gmail.com, Jan 10, 2006.

  1. Guest

    That program does not yield and respond correctly espcially for the
    pointers (*f),(*i)
    in
    print_divide_meter_into(&meter,&yds,&ft,&ins);

    /*--------------pnt02own.c------------
    ---1 inch = 2.51 cm
    ---1 inch = 2.54/100 Meter
    ---1 yard = 3 feet
    ---1 feet = 12 inch
    ---inches=meter/0.0254
    ---feets =meter/0.3048 (0.0254 * 12)
    ---yards =meter/0.9144 (0.0254 * 36)
    ---meter=1/0.0254=39.3700 INCH
    ---meter=1/0.3048=3.28084 FEET
    ---meter=1/0.9144=1.09361 YARDS
    ----------------------------------------------*/
    #include "stdio.h"
    /*Module 2 : using pointers in a function to convert Size Entry
    in meter to sizes of Yards,feet,inches-----*/


    main()
    {
    float meter;
    float yds,ft,ins;
    char another();
    system("cls");
    do {
    input_meter(&meter);
    divide_meter_into(&meter,&yds,&ft,&ins);
    print_divide_meter_into(&meter,&yds,&ft,&ins);
    } while (another()=='y');
    return 0;
    }

    input_meter(float *m)
    {
    printf("\nEnter size in meter :");
    scanf("%f",&(*m));
    printf("\nYou have Entered % f",*m);
    }

    divide_meter_into(float *m,float *y,float *f,float *i)
    {
    float temp_m=0;
    temp_m=(*m)*100.0/2.54;
    (*y)=(temp_m)/36.0;
    (temp_m)=(temp_m)-(*y)*36.0;
    (*f)=(temp_m)/12.0;
    (*i)=(temp_m)-(*f)*12.0;
    printf("\n Meter %f is = %f yards %f feet %f
    inches",(*m),(*y),(*f),(*i));
    }

    print_divide_meter_into(float *m,float *y,float *f,float *i)
    {
    printf("\n Meter %f is = %f yards %f feet %f
    inches",(*m),(*y),(*f),(*i));
    }

    char another()
    {
    char answer;
    printf("\n do ou want to procees (y/n)");
    scanf("\n");
    scanf("%c",&answer);
    return (answer);
    }
    , Jan 10, 2006
    #1
    1. Advertising

  2. On 10 Jan 2006 13:34:36 -0800, in comp.lang.c ,
    wrote:

    Turn up warninglevels in your compiler, as high as they'll go, and fix
    all the errors it now shows you.

    >main()


    int main(). Since 1989, its been considered incorrect to use implicit
    int.

    >{
    >float meter;
    >float yds,ft,ins;


    FYI, most people advise not to use floats for maths, they're too
    imprecise.

    >char another();


    don't declare functions inside other functions - this isn't supported
    in C, and serves no useful purpose.

    >system("cls");


    you don't include the header required for system(), so this won't
    compile.

    >do {
    >input_meter(&meter);


    Your compiler must have complained about this line.... You must
    declare or prototype the function before you can use it. If you don't
    do that, then the arguments are "promoted" according to some rules
    that will cause you problems - floats are promoted to doubles, but
    input_meter expects floats, so it will get bad data since floats are
    not doubles....

    >divide_meter_into(&meter,&yds,&ft,&ins);
    >print_divide_meter_into(&meter,&yds,&ft,&ins);


    same problem for these two...

    >} while (another()=='y');
    >return 0;
    >}
    >
    >input_meter(float *m)


    again, inplicit int. Don't do that - either return void or return an
    int. In this case, void is good.

    void input_meter(float * m)

    >{
    >printf("\nEnter size in meter :");
    >scanf("%f",&(*m));


    scanf("%f", m);

    & and * cancel out. So just "m" will work fine (though if you use
    doubles, you'll want %lf).

    Mind you, scanf is not a safe function. Try typing in "foo" or just
    hitting enter. Read the FAQ for further comments on that.

    >printf("\nYou have Entered % f",*m);
    >}
    >
    >divide_meter_into(float *m,float *y,float *f,float *i)
    >{
    >float temp_m=0;
    >temp_m=(*m)*100.0/2.54;


    100.0 is a double, and your compiler will complain about this since
    you're converting a double into a float and possibly losing data.
    Another reason its easier to use doubles. Also the brackets round *m
    are not needed. Use whitespace if you want to make it clearer


    >(*y)=(temp_m)/36.0;


    the brackets....

    >(temp_m)=(temp_m)-(*y)*36.0;


    and more brackets...

    Oh, and your logic is wrong here - for any y, temp_m==0, not what you
    want. Work it out on paper.

    >(*f)=(temp_m)/12.0;


    brackets...

    >(*i)=(temp_m)-(*f)*12.0;


    etc

    >printf("\n Meter %f is = %f yards %f feet %f inches",(*m),(*y),(*f),(*i));


    yet more unneeded brackets....

    >print_divide_meter_into(float *m,float *y,float *f,float *i)


    no need to pass pointers here, you're not modifying what they point
    to.
    >{
    >printf("\n Meter %f is = %f yards %f feet %f inches",(*m),(*y),(*f),(*i));


    again unneccessary brackets

    Mark McIntyre
    --

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jan 10, 2006
    #2
    1. Advertising

  3. Default User Guest

    wrote:

    > That program does not yield and respond correctly espcially for the
    > pointers (*f),(*i)



    What does this mean? What did you expect it to do? What did it actually
    do?

    We aren't mind readers.



    Brian

    --
    Please quote enough of the previous message for context. To do so from
    Google, click "show options" and use the Reply shown in the expanded
    header.
    Default User, Jan 10, 2006
    #3
  4. Michael Mair Guest

    wrote:
    > That program does not yield and respond correctly espcially for the
    > pointers (*f),(*i)
    > in
    > print_divide_meter_into(&meter,&yds,&ft,&ins);


    Please post code that compiles.
    Yours did not.
    If I fix that and all warnings:

    #include "stdio.h"
    /*Module 2 : using pointers in a function to convert Size Entry
    in meter to sizes of Yards,feet,inches-----*/

    void input_meter(float *m);
    void divide_meter_into(float *m,float *y,float *f,float *i);
    void print_divide_meter_into(float *m, float *y, float *f, float *i);
    char another (void);

    int main (void)
    {
    float meter;
    float yds,ft,ins;
    char another();

    /* system("cls");
    */
    do {
    input_meter(&meter);
    divide_meter_into(&meter,&yds,&ft,&ins);
    print_divide_meter_into(&meter,&yds,&ft,&ins);
    } while (another() == 'y');

    return 0;
    }

    void input_meter(float *m)
    {
    printf("\nEnter size in meter :");
    scanf("%f",&(*m));
    printf("\nYou have Entered % f",*m);
    }

    void divide_meter_into(float *m,float *y,float *f,float *i)
    {
    float temp_m=0;

    temp_m=(*m)*100.0/2.54;
    (*y)=(temp_m)/36.0;
    (temp_m)=(temp_m)-(*y)*36.0;
    (*f)=(temp_m)/12.0;
    (*i)=(temp_m)-(*f)*12.0;
    }

    void print_divide_meter_into(float *m, float *y, float *f, float *i)
    {
    printf("\n Meter %f is = %f yards %f feet"
    " %f inches",(*m),(*y),(*f),(*i));
    }

    char another (void)
    {
    char answer;

    printf("\n do ou want to procees (y/n)");
    scanf("\n");
    scanf("%c",&answer);

    return (answer);
    }


    Back to the original problem:

    <snip!>

    > divide_meter_into(float *m,float *y,float *f,float *i)
    > {
    > float temp_m=0;
    > temp_m=(*m)*100.0/2.54;
    > (*y)=(temp_m)/36.0;
    > (temp_m)=(temp_m)-(*y)*36.0;


    Here, you try to calculate
    temp_m = temp_m - (temp_m/36.0)*36.0;
    Guess what.

    > (*f)=(temp_m)/12.0;
    > (*i)=(temp_m)-(*f)*12.0;
    > printf("\n Meter %f is = %f yards %f feet %f
    > inches",(*m),(*y),(*f),(*i));
    > }


    <snip!>

    What are you trying to do?
    If you want integer division, use integers, "/" and "%".

    The version I think you want:

    #include "stdio.h"
    #include "ctype.h"
    #include "limits.h"


    #define METER_PER_INCH 0.0254


    typedef struct {
    double meter;
    struct {
    double inch;
    long int yard;
    unsigned char foot;
    } imperial;
    } metric_imp;

    int input_meter (double *meters);
    void cleanup_stdin (void);
    void calculate_yfi (metric_imp *in);
    void print_metric_imp (metric_imp *in);
    int do_another (void);

    int main (void)
    {
    metric_imp input = {0};

    do {
    if (input_meter(&input.meter)) {
    calculate_yfi(&input);
    print_metric_imp(&input);
    }
    cleanup_stdin();
    } while (do_another());

    return 0;
    }

    int input_meter(double *m)
    {
    printf("\nEnter size in meter: ");
    fflush(stdout);
    if (1 == scanf("%lf", m)) {
    return 1;
    }
    else {
    fprintf(stderr, "Input error\n");
    return 0;
    }
    }

    void cleanup_stdin (void)
    {
    int c;

    while (EOF != (c=getchar()))
    if (c=='\n')
    break;
    }

    void calculate_yfi (metric_imp *in)
    {
    in->imperial.inch = in->meter / METER_PER_INCH;

    if (in->imperial.inch >= 0
    && in->imperial.inch/36 < LONG_MAX)
    {
    in->imperial.yard = in->imperial.inch/36;
    in->imperial.inch -= in->imperial.yard*36.0;
    in->imperial.foot = in->imperial.inch/12;
    in->imperial.inch -= in->imperial.foot*12.0;
    }
    else {
    in->imperial.yard = in->imperial.foot = 0;
    }
    }

    void print_metric_imp (metric_imp *in)
    {
    printf("\n Meter %g is = %ld yards %d feet"
    " %g inches\n",
    in->meter, in->imperial.yard,
    (int)in->imperial.foot, in->imperial.inch);
    }

    int do_another (void)
    {
    int answer;

    printf("\n Do you want to proceed (y/n)? ");
    fflush(stdout);
    answer = getchar();
    cleanup_stdin();

    return EOF != answer && 'y' == tolower(answer);
    }

    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Jan 10, 2006
    #4
  5. Eric Sosman Guest

    Mark McIntyre wrote On 01/10/06 17:34,:
    > On 10 Jan 2006 13:34:36 -0800, in comp.lang.c ,
    > wrote:
    >
    > Turn up warninglevels in your compiler, as high as they'll go, and fix
    > all the errors it now shows you.
    >
    >
    >>main()

    >
    >
    > int main(). Since 1989, its been considered incorrect to use implicit
    > int.


    s/8/9/ or s/correct/advisable/.

    >
    >>{
    >>float meter;
    >>float yds,ft,ins;

    >
    >
    > FYI, most people advise not to use floats for maths, they're too
    > imprecise.


    "Most people" don't know what they're talking about.
    Besides, precision is clearly not the O.P.'s biggest worry
    (contemplate the table of equivalences at the start of
    his code, and ponder how NASA lost a Mars probe ...)

    >
    >>char another();

    >
    >
    > don't declare functions inside other functions - this isn't supported
    > in C, and serves no useful purpose.


    It's perfectly legal to declare (not define) one function
    inside another, and it serves the useful purpose of providing
    a declaration. It's certainly not the best way to do things,
    but it is "supported by C."

    >
    >>system("cls");

    >
    >
    > you don't include the header required for system(), so this won't
    > compile.


    Legal under C89 rules. Not advisable, but legal.

    >
    >>do {
    >>input_meter(&meter);

    >
    >
    > Your compiler must have complained about this line.... You must
    > declare or prototype the function before you can use it.


    That's the C99 rule, but C89 didn't (or "doesn't," in
    what I'm guessing about the O.P.'s case) doesn't require it.
    It's still a good idea to declare before use, but C89 doesn't
    make it mandatory.

    > If you don't
    > do that, then the arguments are "promoted" according to some rules
    > that will cause you problems - floats are promoted to doubles, but
    > input_meter expects floats, so it will get bad data since floats are
    > not doubles....


    I was just going to let the whole message slide by until
    this piece of misleading misinformation caught my eye. Please
    note that pointers are not subject to promotion, not ever.
    Since `meter' is a float, `&meter' is a float*, and that's
    exactly what input_meter() expects to receive. There's no
    promotion, no bad data, and no error in this line.

    >
    >>divide_meter_into(&meter,&yds,&ft,&ins);
    >>print_divide_meter_into(&meter,&yds,&ft,&ins);

    >
    >
    > same problem for these two...


    Same non-problem for these two.

    >
    >>} while (another()=='y');
    >>return 0;
    >>}
    >>
    >>input_meter(float *m)

    >
    >
    > again, inplicit int. Don't do that - either return void or return an
    > int. In this case, void is good.
    >
    > void input_meter(float * m)
    >
    >
    >>{
    >>printf("\nEnter size in meter :");
    >>scanf("%f",&(*m));

    >
    >
    > scanf("%f", m);
    >
    > & and * cancel out. So just "m" will work fine (though if you use
    > doubles, you'll want %lf).
    >
    > Mind you, scanf is not a safe function. Try typing in "foo" or just
    > hitting enter. Read the FAQ for further comments on that.
    >
    >
    >>printf("\nYou have Entered % f",*m);
    >>}
    >>
    >>divide_meter_into(float *m,float *y,float *f,float *i)
    >>{
    >>float temp_m=0;
    >>temp_m=(*m)*100.0/2.54;

    >
    >
    > 100.0 is a double, and your compiler will complain about this since
    > you're converting a double into a float and possibly losing data.
    > Another reason its easier to use doubles. Also the brackets round *m
    > are not needed. Use whitespace if you want to make it clearer


    Some compilers may complain about converting a double
    to a float (one even complained about `float f = 0.0;'),
    but no complaint is required and the language permits the
    conversion.

    > [remainder snipped]


    --
    Eric Sosman, Jan 10, 2006
    #5
  6. Old Wolf Guest

    Michael Mair wrote:

    > #include "stdio.h"
    > #include "ctype.h"
    > #include "limits.h"


    Causes UB. Should be <stdio.h> etc.

    > typedef struct {
    > double meter;
    > struct {
    > double inch;
    > long int yard;
    > unsigned char foot;
    > } imperial;
    > } metric_imp;


    > void calculate_yfi (metric_imp *in);


    I can't agree with this design choice. In general, you don't want to
    maintain a value in both metric form and imperial form. You have
    a value of one or the other, and convert it as need be.

    Also using only one byte for foot is perhaps questionable (due to
    overflow risk).

    I would far prefer:

    struct imperial
    {
    double inch;
    int foot;
    long yard;
    };

    void calculate_yfi( double metric, struct imperial *imp );

    This also has the advantage that 'metric' cannot be modified
    by the function.

    In fact I would personally go for:

    struct imperial calculate_yfi( double metric)

    but I could understand if you don't like passing structures
    by value.

    > while (EOF != (c=getchar()))
    > if (c=='\n')
    > break;


    Strange that one of the tests is in the while condition and one of
    them is in the body -- I'd prefer to see either both in the condition
    or both in the body.

    > return EOF != answer && 'y' == tolower(answer);


    tolower(EOF) is defined as returning EOF. So simply:

    return 'y' == tolower(answer);
    Old Wolf, Jan 11, 2006
    #6
  7. Michael Mair Guest

    Old Wolf wrote:
    > Michael Mair wrote:
    >
    >>#include "stdio.h"
    >>#include "ctype.h"
    >>#include "limits.h"

    >
    > Causes UB. Should be <stdio.h> etc.


    AFAIK, this is implementation defined at best, as
    after not finding things in implementation defined
    places, #include "foo" is processed as #include <foo>.

    However, you are right; I just took the OP's program
    and modified it.

    >>typedef struct {
    >> double meter;
    >> struct {
    >> double inch;
    >> long int yard;
    >> unsigned char foot;
    >> } imperial;
    >>} metric_imp;

    >
    >
    >>void calculate_yfi (metric_imp *in);

    >
    >
    > I can't agree with this design choice. In general, you don't want to
    > maintain a value in both metric form and imperial form. You have
    > a value of one or the other, and convert it as need be.


    You are right. I just typed ahead and changed the OP's programme
    as I went without giving appropriate consideration to it.
    I just wanted to show the OP a slightly different way.


    > Also using only one byte for foot is perhaps questionable (due to
    > overflow risk).


    Well, the way I proceed, inch is my base unit and I have
    at most 2 ft.

    > I would far prefer:
    >
    > struct imperial
    > {
    > double inch;
    > int foot;
    > long yard;
    > };
    >
    > void calculate_yfi( double metric, struct imperial *imp );


    This is a much better interface.


    > This also has the advantage that 'metric' cannot be modified
    > by the function.
    >
    > In fact I would personally go for:
    >
    > struct imperial calculate_yfi( double metric)
    >
    > but I could understand if you don't like passing structures
    > by value.


    Hmmm, I am a friend of being able to return the error status.

    >> while (EOF != (c=getchar()))
    >> if (c=='\n')
    >> break;

    >
    > Strange that one of the tests is in the while condition and one of
    > them is in the body -- I'd prefer to see either both in the condition
    > or both in the body.


    This is a matter of taste, so I won't discuss it :)


    >> return EOF != answer && 'y' == tolower(answer);

    >
    > tolower(EOF) is defined as returning EOF. So simply:
    >
    > return 'y' == tolower(answer);


    True; I did not look it up.

    Thank you for the corrections!


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Jan 11, 2006
    #7
  8. On 10 Jan 2006 16:21:00 -0800, in comp.lang.c , "Old Wolf"
    <> wrote:

    >Michael Mair wrote:
    >
    >> #include "stdio.h"

    >
    >Causes UB. Should be <stdio.h> etc.


    No, the "" notation causes the compiler to search for headers in an
    implementation defined manner, or if the compiler chooses, identically
    to <> (6.10.2 p3).
    Mark McIntyre
    --

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jan 11, 2006
    #8
  9. On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman
    <> wrote:

    (okay, I'll bite)

    >Mark McIntyre wrote On 01/10/06 17:34,:
    >>
    >> int main(). Since 1989, its been considered incorrect to use implicit
    >> int.

    >
    > s/8/9/ or s/correct/advisable/.


    I disagree. Even though C89 allowed implicit int, its been considered
    a naughty thing to rely on for decades. Sure, you can do it. You can
    also toboggan in the nude.

    >> FYI, most people advise not to use floats for maths, they're too
    >> imprecise.

    >
    > "Most people" don't know what they're talking about.


    I'm sure I've no need to point you at Goldberg. However if the above
    is truly your opinion, I can only assume you do very very little
    maths. However I'm not here to educate you, you're a big boy. :)

    >Besides, precision is clearly not the O.P.'s biggest worry
    >(contemplate the table of equivalences at the start of
    >his code, and ponder how NASA lost a Mars probe ...)


    Oh, sure, whch is why it was an FYI. I wanted to save him some pain
    later on, when he tried some *real* maths.

    >> don't declare functions inside other functions - this isn't supported
    >> in C, and serves no useful purpose.

    >
    > It's perfectly legal to declare (not define) one function
    >inside another,


    my understanding was that it was a GCC extension, but if you can
    provide me a refrence in the standard, I'm happy to be corrected.

    But I am also astonished that you encourage the practice by your
    remarks below. I thought you a better programmer than that.

    >and it serves the useful purpose of providing
    >a declaration. It's certainly not the best way to do things,
    >but it is "supported by C."


    >> Your compiler must have complained about this line.... You must
    >> declare or prototype the function before you can use it.

    >
    > That's the C99 rule, but C89 didn't (or "doesn't," in
    >what I'm guessing about the O.P.'s case) doesn't require it.
    >It's still a good idea to declare before use, but C89 doesn't
    >make it mandatory.


    But no C89 compiler will "let it slide" so my point is entirely valid.
    >this piece of misleading misinformation caught my eye. Please
    >note that pointers are not subject to promotion, not ever.


    Yes, my mistake. Stupid of me.

    >> 100.0 is a double, and your compiler will complain about this


    >but no complaint is required and the language permits the
    >conversion.


    But with a potential loss of data. Which is why compilers complain,
    no? If you have one that doesn't , I suggest you get your wallet out.
    Mark McIntyre
    --

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jan 11, 2006
    #9
  10. Old Wolf Guest

    Mark McIntyre wrote:
    > "Old Wolf" <> wrote:
    >>Michael Mair wrote:
    >>
    >>> #include "stdio.h"

    >>
    >>Causes UB. Should be <stdio.h> etc.

    >
    > No, the "" notation causes the compiler to search for headers in an
    > implementation defined manner, or if the compiler chooses, identically
    > to <> (6.10.2 p3).


    You're right (as is Michael Mair). In fact, N869 6.10.2 says
    that if the "" notation does not find a file, then it MUST be
    reprocessed as if it were the <> notation. (Did this change
    in the final standard?)

    However, I suppose it would be legal for someone to create
    their own "stdio.h" somewhere on the "" search path, though..
    Old Wolf, Jan 12, 2006
    #10
  11. Mike Wahler Guest

    "Mark McIntyre" <> wrote in message
    news:...
    > On 10 Jan 2006 13:34:36 -0800, in comp.lang.c ,
    > wrote:
    >
    > Turn up warninglevels in your compiler, as high as they'll go, and fix
    > all the errors it now shows you.
    >
    >>main()

    >
    > int main(). Since 1989, its been considered incorrect to use implicit
    > int.
    >
    >>{
    >>float meter;
    >>float yds,ft,ins;

    >
    > FYI, most people advise not to use floats for maths, they're too
    > imprecise.
    >
    >>char another();

    >
    > don't declare functions inside other functions - this isn't supported
    > in C,


    It certainly is.

    > and serves no useful purpose.


    It certainly does.

    I'll leave it to others to debate whether declaring
    a function inside another (vs. at file scope) is a good idea.

    -Mike
    Mike Wahler, Jan 12, 2006
    #11
  12. Mark McIntyre <> writes:
    > On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman
    > <> wrote:

    [...]
    >>Mark McIntyre wrote On 01/10/06 17:34,:
    >>>
    >>> int main(). Since 1989, its been considered incorrect to use implicit
    >>> int.

    >>
    >> s/8/9/ or s/correct/advisable/.

    >
    > I disagree. Even though C89 allowed implicit int, its been considered
    > a naughty thing to rely on for decades. Sure, you can do it. You can
    > also toboggan in the nude.


    Every conforming C89/C90 implementation is required to support
    implicit int. The C90 standard doesn't even list it as an obsolescent
    feature in section 6.9, "Future language directions", though it does
    say that non-prototype function declarations are obsolescent.

    Yes, using implicit int is a bad idea, and nobody is advocating it.
    But since it was clearly part of the C90 language, it's more accurate
    to say that it's inadvisable than to say that it's "incorrect".

    --
    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, Jan 12, 2006
    #12
  13. On Thu, 12 Jan 2006 01:17:12 GMT, in comp.lang.c , Keith Thompson
    <> wrote:

    >Every conforming C89/C90 implementation is required to support
    >implicit int. The C90 standard doesn't even list it as an obsolescent
    >feature in section 6.9, "Future language directions", though it does
    >say that non-prototype function declarations are obsolescent.


    I agree with this, my point is that in all my experience its been
    considered exceptionally bad practice for at least a decade.

    >Yes, using implicit int is a bad idea, and nobody is advocating it.


    I disagree. Eric's post pretty much said "go ahead, thats fine"

    >But since it was clearly part of the C90 language, it's more accurate
    >to say that it's inadvisable than to say that it's "incorrect".


    YMMV.
    Mark McIntyre
    --

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jan 12, 2006
    #13
  14. Mark McIntyre <> writes:
    > On Thu, 12 Jan 2006 01:17:12 GMT, in comp.lang.c , Keith Thompson
    > <> wrote:
    >
    >>Every conforming C89/C90 implementation is required to support
    >>implicit int. The C90 standard doesn't even list it as an obsolescent
    >>feature in section 6.9, "Future language directions", though it does
    >>say that non-prototype function declarations are obsolescent.

    >
    > I agree with this, my point is that in all my experience its been
    > considered exceptionally bad practice for at least a decade.
    >
    >>Yes, using implicit int is a bad idea, and nobody is advocating it.

    >
    > I disagree. Eric's post pretty much said "go ahead, thats fine"


    No, I don't think that's what he said at all. Here's the relevant
    snippet from his article:

    ] Mark McIntyre wrote On 01/10/06 17:34,:
    ] > On 10 Jan 2006 13:34:36 -0800, in comp.lang.c ,
    ] > wrote:
    ] >
    ] > Turn up warninglevels in your compiler, as high as they'll go, and fix
    ] > all the errors it now shows you.
    ] >
    ] >
    ] >>main()
    ] >
    ] >
    ] > int main(). Since 1989, its been considered incorrect to use implicit
    ] > int.
    ]
    ] s/8/9/ or s/correct/advisable/.
    ]
    ] >

    So with his suggested correction applied, the sentence becomes either

    Since 1989, its been considered inadvisable to use implicit int.

    or

    Since 1999, its been considered incorrect to use implicit int.

    Neither of those statements says "go ahead, that's fine". (Did you
    misread the correction and think the modified sentence would say
    "advisable" rather than "inadvisable"?)

    --
    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, Jan 12, 2006
    #14
  15. Eric Sosman Guest

    Mark McIntyre wrote On 01/12/06 18:40,:
    > On Thu, 12 Jan 2006 01:17:12 GMT, in comp.lang.c , Keith Thompson
    > <> wrote:
    >
    >
    >>Every conforming C89/C90 implementation is required to support
    >>implicit int. The C90 standard doesn't even list it as an obsolescent
    >>feature in section 6.9, "Future language directions", though it does
    >>say that non-prototype function declarations are obsolescent.

    >
    >
    > I agree with this, my point is that in all my experience its been
    > considered exceptionally bad practice for at least a decade.
    >
    >
    >>Yes, using implicit int is a bad idea, and nobody is advocating it.

    >
    >
    > I disagree. Eric's post pretty much said "go ahead, thats fine"


    Eric's post said it was "inadvisable." Mark's post said
    "Since 1989, it's been considered incorrect."

    --
    Eric Sosman, Jan 13, 2006
    #15
  16. In article <>,
    Mark McIntyre <> wrote:
    >On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman
    ><> wrote:

    ....
    >> It's perfectly legal to declare (not define) one function

    ^^^^^^^
    >>inside another,

    >
    >my understanding was that it was a GCC extension, but if you can
    >provide me a refrence in the standard, I'm happy to be corrected.


    He said "declare", not "define". Big difference. GCC does, indeed, allow
    nested definitions (as an extension).

    The following is entirely legal (though possibly misguided) (stock) C:

    int myfun(void) { char *funofmine(void); char *s = funofmine(); return strlen(s); }
    char *funofmine(void) { return "This is a test"; }

    But we all know it is better to:
    a) Declare/prototype all functions "globally" (at file scope).
    b) Do so in header files.

    >But I am also astonished that you encourage the practice by your
    >remarks below. I thought you a better programmer than that.


    He did not "encourage" it - he just said it was "OK" (as in legal).
    See above.
    Kenny McCormack, Jan 13, 2006
    #16
  17. On Thu, 12 Jan 2006 23:55:30 GMT, in comp.lang.c , Keith Thompson
    <> wrote:

    >No, I don't think that's what he said at all. Here's the relevant
    >snippet from his article:


    no, thats not the relevant snippet. This is the relevant snippet:

    On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman
    <> wrote:
    > It's perfectly legal to declare (not define) one function
    >inside another, and it serves the useful purpose of providing
    >a declaration.


    This seems to me to say "its fine to do this". even if...

    >It's certainly not the best way to do things, but it is "supported by C."


    .... this bit notes that its not the best way.

    As I earlier noted, I had the impression that even a declaration was a
    gcc extension, but I've no problem about being mistaken.

    And now back to something you said:

    >misread the correction and think the modified sentence would say
    >"advisable" rather than "inadvisable"?)


    I suspect that after a couple of decades of using unix I can read
    basic sed. No offense taken though.
    Mark McIntyre
    --

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jan 13, 2006
    #17
  18. Mark McIntyre <> writes:
    > On Thu, 12 Jan 2006 23:55:30 GMT, in comp.lang.c , Keith Thompson
    > <> wrote:
    >
    >>No, I don't think that's what he said at all. Here's the relevant
    >>snippet from his article:

    >
    > no, thats not the relevant snippet. This is the relevant snippet:
    >
    > On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman
    > <> wrote:
    >> It's perfectly legal to declare (not define) one function
    >>inside another, and it serves the useful purpose of providing
    >>a declaration.

    >
    > This seems to me to say "its fine to do this". even if...
    >
    >>It's certainly not the best way to do things, but it is "supported by C."

    >
    > ... this bit notes that its not the best way.
    >
    > As I earlier noted, I had the impression that even a declaration was a
    > gcc extension, but I've no problem about being mistaken.


    [snip]

    I'm a little tired of arguing about what was said rather than
    discussing the C language, but ...

    In context, it was clearly implicit int that was being discussed, not
    function declarations inside functions.

    Here's what you posted just upthread (see
    <http://groups.google.com/group/comp.lang.c/msg/9ebe6ac1b8bb6d8f>):

    ] On Thu, 12 Jan 2006 01:17:12 GMT, in comp.lang.c , Keith Thompson
    ] <> wrote:
    ]
    ] >Every conforming C89/C90 implementation is required to support
    ] >implicit int. The C90 standard doesn't even list it as an obsolescent
    ] >feature in section 6.9, "Future language directions", though it does
    ] >say that non-prototype function declarations are obsolescent.
    ]
    ] I agree with this, my point is that in all my experience its been
    ] considered exceptionally bad practice for at least a decade.
    ]
    ] >Yes, using implicit int is a bad idea, and nobody is advocating it.
    ]
    ] I disagree. Eric's post pretty much said "go ahead, thats fine"
    ]
    ] >But since it was clearly part of the C90 language, it's more accurate
    ] >to say that it's inadvisable than to say that it's "incorrect".
    ]
    ] YMMV.
    ] Mark McIntyre

    Whatever you intended to write, what you actually wrote was that Eric
    had said "go ahead, thats fine" with respect to implicit int. In
    fact, he didn't; he clearly said it's inadvisable.

    Function declarations within function bodies are a different subject.
    I don't use them myself, but I can imagine that there might be a
    perfectly good reason to do so. For example, suppose a source file
    contains a number of function definitions. Function foo_assistant()
    is used only by function foo(), not by anything else in the file. In
    this case, putting a declaration of foo_assistant() inside the body of
    foo() could be a way of documenting the fact that only foo() is
    intended to use it. (If the language permitted it, it would make
    sense to *define* foo_assistent() inside foo(), but of course it
    doesn't.)

    --
    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, Jan 14, 2006
    #18
  19. On Sat, 14 Jan 2006 00:14:31 GMT, in comp.lang.c , Keith Thompson
    <> wrote:

    >I'm a little tired of arguing about what was said rather than
    >discussing the C language, but ...


    Then lets stop.

    Eric's post said "this technique can be used and is useful". In my
    opinion, posting such comments to obvious newbies is foolish in the
    extreme, the impression clearly given was that it was ok to use it,
    which again in my opinion it most certainly is not.

    And forgive me for being blunt, but I believe you're arguing with me
    mostly because you've taken a dislike to my posting style. I'm, sure
    that you are of the opinion that you're arguing because I'm factually
    wrong. Thats as may be, but I'm coming close to plonking you because
    I find it tedious to spend so much time dealing with trivia. Perhaps
    you should do the same to me, so that you can avoid being upset.

    Both would be a shame for me because I value your C posts, and
    appreciate your reasonable corrections or additions to mine. The value
    is however close to being outweighed by the constant sniping.
    Mark McIntyre
    --

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jan 14, 2006
    #19
  20. Mark McIntyre <> writes:
    > On Sat, 14 Jan 2006 00:14:31 GMT, in comp.lang.c , Keith Thompson
    > <> wrote:
    >>I'm a little tired of arguing about what was said rather than
    >>discussing the C language, but ...

    >
    > Then lets stop.
    >
    > Eric's post said "this technique can be used and is useful". In my
    > opinion, posting such comments to obvious newbies is foolish in the
    > extreme, the impression clearly given was that it was ok to use it,
    > which again in my opinion it most certainly is not.


    Which technique are you referring to? There were two distinct
    techniques under discussion, implicit int and function declarations
    within function definitions.

    Let's summarize some things I hope we can agree on and move on.

    Eric did not say or imply that implicit int is useful. He merely
    pointed out that it's legal (but inadvisable) in C89 and illegal in
    C99. I agree with him on both points.

    Eric did say that function declarations inside function definitions
    are perfectly legal and can serve a useful purpose. You obviously
    feel strongly that they're a bad idea. They don't particularly bother
    me, and I can imagine circumstances in which they *might* be a good
    approach. Since they're unquestionably legal, we can agree to
    disagree on the style issue -- and I'll avoid using them in any code I
    post here. (I'll note that you had previously assumed they were a gcc
    extension, which might have colored your opinion of them -- but
    regardless of that, your opinion that they're a bad idea is perfectly
    valid.)

    I believe the impression has been given in this thread that Eric was
    endorsing the use of implicit int. Since that would be, IMHO, a
    foolish thing for Eric to say, and since Eric in fact didn't say that,
    I thought it was important to set the record straight.

    --
    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, Jan 14, 2006
    #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. Andy
    Replies:
    7
    Views:
    6,254
    Roedy Green
    May 10, 2004
  2. Jim West
    Replies:
    4
    Views:
    1,433
    Jeff Schwab
    Jan 16, 2004
  3. bd
    Replies:
    0
    Views:
    621
  4. Carsten Fuchs
    Replies:
    45
    Views:
    1,536
    James Kanze
    Oct 8, 2009
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    672
Loading...

Share This Page