Is this C program doing what it is supposed to do ?

Discussion in 'C Programming' started by John, Jan 30, 2011.

  1. John

    John Guest

    The program is supposed to read lines from the standard input, then each line is printed on the standard output preceded by its line number. The program should have no built-on limit on how long a line it can handle.

    So I wrote the following program in C, but I'm not sure that it is doing what it is supposed to do. I verified the source code against the solution in the back of the book and I'm pasting here what the solution in the back of the book is.

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

    int main(){

    int ch;
    int at_beginning = 1;
    int line = 0;

    while( (ch==getchar())!= EOF){

    if(at_beginning == 1){

    at_beginning = 0;
    line+=1;
    printf("%d ", line);

    }

    putchar(ch);

    if(ch == '\n')
    at_beginning = 1;
    }
    return EXIT_SUCCESS;
    }
     
    John, Jan 30, 2011
    #1
    1. Advertising

  2. John

    Eric Sosman Guest

    On 1/30/2011 4:08 PM, John wrote:
    > The program is supposed to read lines from the standard input, then each line is printed on the standard output preceded by its line number. The program should have no built-on limit on how long a line it can handle.
    >
    > So I wrote the following program in C, but I'm not sure that it is doing what it is supposed to do. I verified the source code against the solution in the back of the book and I'm pasting here what the solution in the back of the book is.
    >
    > #include<stdio.h>
    > #include<stdlib.h>
    >
    > int main(){
    >
    > int ch;
    > int at_beginning = 1;
    > int line = 0;
    >
    > while( (ch==getchar())!= EOF){


    You want `=' instead of `==' here. (This may be the first time
    I've seen the "equals/assign" mistake in this direction; usually, it's
    using `=' where `==' is meant, not the other way around.)

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 30, 2011
    #2
    1. Advertising

  3. John <> writes:

    > The program is supposed to read lines from the standard input, then each line is printed on the standard output preceded by its line number. The program should have no built-on limit on how long a line it can handle.
    >
    > So I wrote the following program in C, but I'm not sure that it is doing what it is supposed to do. I verified the source code against the solution in the back of the book and I'm pasting here what the solution in the back of the book is.
    >
    > #include<stdio.h>
    > #include<stdlib.h>
    >
    > int main(){


    int main(void) is better. It hardly matters for main, but for other
    functions using the form with void will enable proper function prototype
    checking so it's worth getting into the habit.

    > int ch;
    > int at_beginning = 1;
    > int line = 0;
    >
    > while( (ch==getchar())!= EOF){


    == confused with = already commented on.

    > if(at_beginning == 1){


    It's usually better to write:

    if (at_beginning) { ...

    > at_beginning = 0;
    > line+=1;
    > printf("%d ", line);
    >
    > }
    >
    > putchar(ch);
    >
    > if(ch == '\n')
    > at_beginning = 1;


    and here I'd write

    at_beginning = ch == '\n';

    This way the reader can see at once when at_beginning is 0 and when it
    is 1. The earlier assignment becomes redundant.

    > }
    > return EXIT_SUCCESS;
    > }


    --
    Ben.
     
    Ben Bacarisse, Jan 30, 2011
    #3
  4. John

    Chris H Guest

    In message <0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    me.uk>, Ben Bacarisse <> writes
    >> if(at_beginning == 1){

    >
    >It's usually better to write:
    >
    > if (at_beginning) { ...


    No it isn't

    >> if(ch == '\n')
    >> at_beginning = 1;

    >
    >and here I'd write
    >
    > at_beginning = ch == '\n';


    Appalling! And dangerous.




    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Jan 31, 2011
    #4
  5. John

    Eric Sosman Guest

    On 1/31/2011 4:05 AM, Chris H wrote:
    > In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    > me.uk>, Ben Bacarisse<> writes
    >>> if(at_beginning == 1){

    >>
    >> It's usually better to write:
    >>
    >> if (at_beginning) { ...

    >
    > No it isn't


    De gustibus non disputandum est.

    >>> if(ch == '\n')
    >>> at_beginning = 1;

    >>
    >> and here I'd write
    >>
    >> at_beginning = ch == '\n';

    >
    > Appalling! And dangerous.


    Balderdash! And ignorant.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 31, 2011
    #5
  6. John

    Chris H Guest

    In message <ii69dn$6vh$-september.org>, Eric Sosman
    <> writes
    >On 1/31/2011 4:05 AM, Chris H wrote:
    >> In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >> me.uk>, Ben Bacarisse<> writes
    >>>> if(at_beginning == 1){
    >>>
    >>> It's usually better to write:
    >>>
    >>> if (at_beginning) { ...

    >>
    >> No it isn't

    >
    > De gustibus non disputandum est.
    >
    >>>> if(ch == '\n')
    >>>> at_beginning = 1;
    >>>
    >>> and here I'd write
    >>>
    >>> at_beginning = ch == '\n';

    >>
    >> Appalling! And dangerous.

    >
    > Balderdash! And ignorant.


    The OP has already made one mistake with = and ==
    The line is dangerous.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Jan 31, 2011
    #6
  7. Chris H <> writes:

    > In message <ii69dn$6vh$-september.org>, Eric Sosman
    > <> writes
    >>On 1/31/2011 4:05 AM, Chris H wrote:
    >>> In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >>> me.uk>, Ben Bacarisse<> writes
    >>>>> if(at_beginning == 1){
    >>>>
    >>>> It's usually better to write:
    >>>>
    >>>> if (at_beginning) { ...
    >>>
    >>> No it isn't

    >>
    >> De gustibus non disputandum est.
    >>
    >>>>> if(ch == '\n')
    >>>>> at_beginning = 1;
    >>>>
    >>>> and here I'd write
    >>>>
    >>>> at_beginning = ch == '\n';
    >>>
    >>> Appalling! And dangerous.

    >>
    >> Balderdash! And ignorant.

    >
    > The OP has already made one mistake with = and ==
    > The line is dangerous.


    The original code (to which I was offering this alternative) has the
    same set of operators so it would seem to offer the same opportunities
    for =/== confusion. You also snipped my supporting argument. What is
    your argument in support of the original (or against my alternative)?

    --
    Ben.
     
    Ben Bacarisse, Jan 31, 2011
    #7
  8. John

    Chris H Guest

    In message <0.c67692d26d53aa1f6676.20110131132623GMT.87ei7t5hmo.fsf@bsb.
    me.uk>, Ben Bacarisse <> writes
    >Chris H <> writes:
    >
    >> In message <ii69dn$6vh$-september.org>, Eric Sosman
    >> <> writes
    >>>On 1/31/2011 4:05 AM, Chris H wrote:
    >>>> In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >>>> me.uk>, Ben Bacarisse<> writes
    >>>>>> if(at_beginning == 1){
    >>>>>
    >>>>> It's usually better to write:
    >>>>>
    >>>>> if (at_beginning) { ...
    >>>>
    >>>> No it isn't
    >>>
    >>> De gustibus non disputandum est.
    >>>
    >>>>>> if(ch == '\n')
    >>>>>> at_beginning = 1;
    >>>>>
    >>>>> and here I'd write
    >>>>>
    >>>>> at_beginning = ch == '\n';
    >>>>
    >>>> Appalling! And dangerous.
    >>>
    >>> Balderdash! And ignorant.

    >>
    >> The OP has already made one mistake with = and ==
    >> The line is dangerous.

    >
    >The original code (to which I was offering this alternative) has the
    >same set of operators so it would seem to offer the same opportunities
    >for =/== confusion. You also snipped my supporting argument. What is
    >your argument in support of the original (or against my alternative)?


    Er what argument for it? There wasn't one.


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Jan 31, 2011
    #8
  9. Chris H wrote:
    > In message
    > <0.c67692d26d53aa1f6676.20110131132623GMT.87ei7t5hmo.fsf@bsb. me.uk>,
    > Ben Bacarisse <> writes
    >> Chris H <> writes:
    >>
    >>> In message <ii69dn$6vh$-september.org>, Eric Sosman
    >>> <> writes
    >>>> On 1/31/2011 4:05 AM, Chris H wrote:
    >>>>> In
    >>>>> message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >>>>> me.uk>, Ben Bacarisse<> writes
    >>>>>>> if(at_beginning == 1){
    >>>>>>
    >>>>>> It's usually better to write:
    >>>>>>
    >>>>>> if (at_beginning) { ...
    >>>>>
    >>>>> No it isn't
    >>>>
    >>>> De gustibus non disputandum est.
    >>>>
    >>>>>>> if(ch == '\n')
    >>>>>>> at_beginning = 1;
    >>>>>>
    >>>>>> and here I'd write
    >>>>>>
    >>>>>> at_beginning = ch == '\n';
    >>>>>
    >>>>> Appalling! And dangerous.
    >>>>
    >>>> Balderdash! And ignorant.
    >>>
    >>> The OP has already made one mistake with = and ==
    >>> The line is dangerous.

    >>
    >> The original code (to which I was offering this alternative) has the
    >> same set of operators so it would seem to offer the same
    >> opportunities for =/== confusion. You also snipped my supporting
    >> argument. What is your argument in support of the original (or
    >> against my alternative)?

    >
    > Er what argument for it? There wasn't one.


    This one :
    > This way the reader can see at once when at_beginning is 0 and when it
    > is 1. The earlier assignment becomes redundant.


    Bye, Jojo
     
    Joachim Schmitz, Jan 31, 2011
    #9
  10. John

    Chris H Guest

    In message <ii6ift$9k$>, Joachim Schmitz
    <> writes
    >Chris H wrote:
    >> In message
    >> <0.c67692d26d53aa1f6676.20110131132623GMT.87ei7t5hmo.fsf@bsb. me.uk>,
    >> Ben Bacarisse <> writes
    >>> Chris H <> writes:
    >>>
    >>>> In message <ii69dn$6vh$-september.org>, Eric Sosman
    >>>> <> writes
    >>>>> On 1/31/2011 4:05 AM, Chris H wrote:
    >>>>>> In
    >>>>>> message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >>>>>> me.uk>, Ben Bacarisse<> writes
    >>>>>>>> if(at_beginning == 1){
    >>>>>>> It's usually better to write:
    >>>>>>> if (at_beginning) { ...
    >>>>>> No it isn't
    >>>>> De gustibus non disputandum est.
    >>>>>
    >>>>>>>> if(ch == '\n')
    >>>>>>>> at_beginning = 1;
    >>>>>>> and here I'd write
    >>>>>>> at_beginning = ch == '\n';
    >>>>>> Appalling! And dangerous.
    >>>>> Balderdash! And ignorant.
    >>>> The OP has already made one mistake with = and ==
    >>>> The line is dangerous.
    >>> The original code (to which I was offering this alternative) has
    >>>the
    >>> same set of operators so it would seem to offer the same
    >>> opportunities for =/== confusion. You also snipped my supporting
    >>> argument. What is your argument in support of the original (or
    >>> against my alternative)?

    >> Er what argument for it? There wasn't one.

    >
    >This one :
    >> This way the reader can see at once when at_beginning is 0 and when it
    >> is 1. The earlier assignment becomes redundant.

    >
    >Bye, Jojo
    >


    So there is no argument to support it then and it is dangerous.





    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Jan 31, 2011
    #10
  11. John

    Rui Maciel Guest

    Chris H wrote:

    > Er what argument for it? There wasn't one.


    You are free to read Ben's post, the one which you replied to.

    In spite of this, if you wish to present a better alternative you are
    compelled to demonstrate why your suggestion is better.


    Rui Maciel
     
    Rui Maciel, Jan 31, 2011
    #11
  12. Chris H <> writes:
    > In message <0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    > me.uk>, Ben Bacarisse <> writes
    >>> if(at_beginning == 1){

    >>
    >>It's usually better to write:
    >>
    >> if (at_beginning) { ...

    >
    > No it isn't


    Why? I've read several other followups in this thread, and I
    haven't seen you provide any supporting arguments for this.

    at_beginning is treated as a boolean. It would make sense to declare it
    as bool or _Bool if the compiler supports it. Why is an explicit
    comparison against 1 better than a simple test of the variable?

    "if (at_beginning)" expresses the intent more clearly than
    "if (at_beginning == 1)". And since "==" yields a logically boolean
    result, why stop at one "=="; why not write
    "if ((at_beginning == 1) == 1)"?

    In this particular case, at_beginning can only have the value 0 or
    1, but of course any non-zero value is treated as true. What if,
    in a later version of the program, at_beginning is assigned the
    result of one of the is*() functions?

    >>> if(ch == '\n')
    >>> at_beginning = 1;

    >>
    >>and here I'd write
    >>
    >> at_beginning = ch == '\n';

    >
    > Appalling! And dangerous.


    I presume there's some reason behind your reaction, but I honestly
    can't think of what it might be. Yes, the OP made an "=" vs. "=="
    error. Surely the solution is to avoid making such errors --
    which, I think, are no more likely with the suggested change than
    without it.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 31, 2011
    #12
  13. John

    Ian Collins Guest

    On 02/ 1/11 05:13 AM, Keith Thompson wrote:
    > Chris H<> writes:
    >> In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >> me.uk>, Ben Bacarisse<> writes
    >>>
    >>> and here I'd write
    >>>
    >>> at_beginning = ch == '\n';

    >>
    >> Appalling! And dangerous.

    >
    > I presume there's some reason behind your reaction, but I honestly
    > can't think of what it might be. Yes, the OP made an "=" vs. "=="
    > error. Surely the solution is to avoid making such errors --
    > which, I think, are no more likely with the suggested change than
    > without it.


    at_beginning = (ch == '\n');

    is probably clearer to many.

    --
    Ian Collins
     
    Ian Collins, Jan 31, 2011
    #13
  14. John

    Rui Maciel Guest

    Richard Harter wrote:

    > He is not compelled to do any such thing. This being usenet, he can
    > post pretty much anything that he wants to. You may well feel that he
    > has an obligation to explain himself, and I would agree with you, but
    > again he is quite at liberty to ignore our feelings in the mat


    This is a public forum dedicated to the discussion of a series of
    technical issues involving a specific programming language.

    With this in mind, if someone wishes to participate in a discussion on
    any technical issue involving this particular programming language and he
    wishes to do so by throwing criticism at other people's work then, at the
    very least, that person must be able to objectively base his comments in
    any tangible and reasonable technical aspect. Otherwise their criticism
    only contributes to the noise level in this newsgroup.

    In this case, we saw a user throwing baseless claims that he is unable to
    substantiate. This is pure noise and lacks any value. So, by pointing
    out that if someone wishes to badmouth other people's work then that
    person is compelled to base their claims, in essence what's being told is
    that this sort of critics should either put up or shut up. Otherwise no
    one stands to gain anything from this sort of behavior.


    Rui Maciel
     
    Rui Maciel, Jan 31, 2011
    #14
  15. John

    Chris H Guest

    In message <4d471117$0$20190$>, Rui Maciel
    <> writes
    >Richard Harter wrote:
    >
    >> He is not compelled to do any such thing. This being usenet, he can
    >> post pretty much anything that he wants to. You may well feel that he
    >> has an obligation to explain himself, and I would agree with you, but
    >> again he is quite at liberty to ignore our feelings in the mat

    >
    >This is a public forum dedicated to the discussion of a series of
    >technical issues involving a specific programming language.
    >
    >With this in mind, if someone wishes to participate in a discussion on
    >any technical issue involving this particular programming language and he
    >wishes to do so by throwing criticism at other people's work then, at the
    >very least, that person must be able to objectively base his comments in
    >any tangible and reasonable technical aspect. Otherwise their criticism
    >only contributes to the noise level in this newsgroup.
    >
    >In this case, we saw a user throwing baseless claims that he is unable to
    >substantiate.


    Can you prove that statement?

    > This is pure noise and lacks any value. So, by pointing
    >out that if someone wishes to badmouth other people's work then that
    >person is compelled to base their claims, in essence what's being told is
    >that this sort of critics should either put up or shut up. Otherwise no
    >one stands to gain anything from this sort of behavior.
    >
    >
    >Rui Maciel


    Now I know why I so rarely post to this forum

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Jan 31, 2011
    #15
  16. Chris H <> writes:
    > In message <4d471117$0$20190$>, Rui Maciel
    > <> writes

    [...]
    >> This is pure noise and lacks any value. So, by pointing
    >>out that if someone wishes to badmouth other people's work then that
    >>person is compelled to base their claims, in essence what's being told is
    >>that this sort of critics should either put up or shut up. Otherwise no
    >>one stands to gain anything from this sort of behavior.

    >
    > Now I know why I so rarely post to this forum


    Chris, I hope this discussion won't prevent you from sharing with
    us the reasoning behind your statements. I really would like to
    know what you had in mind.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 31, 2011
    #16
  17. Ian Collins <> writes:
    > On 02/ 1/11 05:13 AM, Keith Thompson wrote:
    >> Chris H<> writes:
    >>> In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >>> me.uk>, Ben Bacarisse<> writes
    >>>>
    >>>> and here I'd write
    >>>>
    >>>> at_beginning = ch == '\n';
    >>>
    >>> Appalling! And dangerous.

    >>
    >> I presume there's some reason behind your reaction, but I honestly
    >> can't think of what it might be. Yes, the OP made an "=" vs. "=="
    >> error. Surely the solution is to avoid making such errors --
    >> which, I think, are no more likely with the suggested change than
    >> without it.

    >
    > at_beginning = (ch == '\n');
    >
    > is probably clearer to many.


    Agreed. I'd probably write it that way myself.

    I think some people have a little trouble with the idea of using
    Boolean values and expressions in contexts other than explicit
    conditions. (By "Boolean", I don't necessarily mean something of
    type bool or _Bool, just something that's logically true-or-false.
    C has traditionally used int for this purpose.) If you don't think
    of a Boolean value as a value, it makes sense to write something like

    if (foo == bar) {
    flag = 1;
    }
    else {
    flag = 0;
    }

    rather than just

    flag = (foo == bar);

    whereas I rather strongly prefer the latter.

    I'm not saying that that's Chris H's issue. I still don't know
    what he's complaining about, but I'd like to.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 31, 2011
    #17
  18. Keith Thompson <> writes:
    > Ian Collins <> writes:
    >> On 02/ 1/11 05:13 AM, Keith Thompson wrote:
    >>> Chris H<> writes:
    >>>> In message<0.8a2a169873977757779c.20110130214737GMT.87k4hm5aiu.fsf@bsb.
    >>>> me.uk>, Ben Bacarisse<> writes
    >>>>>
    >>>>> and here I'd write
    >>>>>
    >>>>> at_beginning = ch == '\n';
    >>>>
    >>>> Appalling! And dangerous.
    >>>
    >>> I presume there's some reason behind your reaction, but I honestly
    >>> can't think of what it might be. Yes, the OP made an "=" vs. "=="
    >>> error. Surely the solution is to avoid making such errors --
    >>> which, I think, are no more likely with the suggested change than
    >>> without it.

    >>
    >> at_beginning = (ch == '\n');
    >>
    >> is probably clearer to many.

    >
    > Agreed. I'd probably write it that way myself.
    >
    > I think some people have a little trouble with the idea of using
    > Boolean values and expressions in contexts other than explicit
    > conditions. (By "Boolean", I don't necessarily mean something of
    > type bool or _Bool, just something that's logically true-or-false.
    > C has traditionally used int for this purpose.) If you don't think
    > of a Boolean value as a value, it makes sense to write something like
    >
    > if (foo == bar) {
    > flag = 1;
    > }
    > else {
    > flag = 0;
    > }
    >
    > rather than just
    >
    > flag = (foo == bar);
    >
    > whereas I rather strongly prefer the latter.
    >
    > I'm not saying that that's Chris H's issue. I still don't know
    > what he's complaining about, but I'd like to.


    Hmm. My comments above were based mostly on the responses; I hadn't
    looked closely at the original code, and I made some incorrect
    assumptions about it. Now that I look at it, the issue isn't as
    straightforward as I had assumed.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 31, 2011
    #18
  19. Richard wrote:
    > Keith Thompson<> writes:
    >> I think some people have a little trouble with the idea of using
    >> Boolean values and expressions in contexts other than explicit
    >> conditions. (By "Boolean", I don't necessarily mean something of
    >> type bool or _Bool, just something that's logically true-or-false.
    >> C has traditionally used int for this purpose.) If you don't think
    >> of a Boolean value as a value, it makes sense to write something like
    >>
    >> if (foo == bar) {
    >> flag = 1;
    >> }
    >> else {
    >> flag = 0;
    >> }
    >>
    >> rather than just
    >>
    >> flag = (foo == bar);
    >>
    >> whereas I rather strongly prefer the latter.
    >>
    >> I'm not saying that that's Chris H's issue. I still don't know
    >> what he's complaining about, but I'd like to.

    >
    > You never cease to amaze. You really think an embedded systems C
    > programmer has a problem with such a basic C concept?


    Obviously your opinion about the average programming skills of embedded
    systems C programmers is higher than mine ;->

    (Disclaimer: No offence to anyone in particular intended. And I said
    *average* skills, not Chris H's skills.)
    --
    Marcin Grzegorczyk
     
    Marcin Grzegorczyk, Jan 31, 2011
    #19
  20. John

    Walter Banks Guest

    Richard wrote:

    > You never cease to amaze. You really think an embedded systems C
    > programmer has a problem with such a basic C concept?


    Nothing would surprise in what a C programmer might do. I wish
    I had a nickel for every support call I have taken in the last quarter
    century when = and == were confused or a define had a ';' at the
    end creating macro expansion with unexpected results.


    Regards,


    w..
    --
    Walter Banks
    Byte Craft Limited
    http://www.bytecraft.com
     
    Walter Banks, Jan 31, 2011
    #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. ThunderMusic

    How I'm I supposed to use string tables?

    ThunderMusic, Oct 15, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    456
    John Saunders
    Oct 15, 2004
  2. Simon Harvey
    Replies:
    5
    Views:
    452
    Scott M.
    Nov 16, 2003
  3. Jan Nielsen
    Replies:
    7
    Views:
    535
    Jan Nielsen
    Feb 8, 2005
  4. Replies:
    3
    Views:
    1,520
  5. devkays
    Replies:
    1
    Views:
    245
    Ian Collins
    Jan 30, 2011
Loading...

Share This Page