program output?

Discussion in 'C Programming' started by bnp, May 24, 2004.

  1. bnp

    bnp Guest

    Hi,

    I took a test on C.
    there was an objective question for program output type.
    following is the program:

    main()
    {
    char ch;
    int i =2;
    for (ch=0;ch<128;ch++)
    i+=2;
    printf("%d",i);
    }
    i wrote the answer 256 will be printed.
    But our instructor told me that it will be infinite loop.
    Is that right, I am not sure of the answer.

    Regards,

    Bhavik
    bnp, May 24, 2004
    #1
    1. Advertising

  2. bnp

    Leor Zolman Guest

    On 24 May 2004 04:20:00 -0700, (bnp) wrote:

    >Hi,
    >
    >I took a test on C.
    >there was an objective question for program output type.
    >following is the program:
    >
    >main()
    >{
    >char ch;
    >int i =2;
    >for (ch=0;ch<128;ch++)
    >i+=2;
    >printf("%d",i);
    >}
    >i wrote the answer 256 will be printed.
    >But our instructor told me that it will be infinite loop.
    >Is that right, I am not sure of the answer.


    Kinda tricky.
    First of all, the default "signedness" of the char type is
    platform-dependent. If it is 8 bits and "signed", as is the default on
    typical PC-based platforms, then this does indeed go into an infinite loop.
    In that case, the range of values for an 8-bit char is -128 to +127. It
    will always be less than +128.

    If the default for chars is unsigned, then the program output is 258 [I
    didn't figure it out, I just ran it ;-) ]
    -leor

    >
    >Regards,
    >
    >Bhavik


    --
    Leor Zolman --- BD Software --- www.bdsoft.com
    On-Site Training in C/C++, Java, Perl and Unix
    C++ users: download BD Software's free STL Error Message Decryptor at:
    www.bdsoft.com/tools/stlfilt.html
    Leor Zolman, May 24, 2004
    #2
    1. Advertising

  3. On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:

    > Hi,
    >
    > I took a test on C.
    > there was an objective question for program output type.
    > following is the program:
    >
    > main()


    int main () or int main (void) is preferred.

    > {


    Proper indentation is a Good Thing(tm), even for trivial examples such as
    this.

    > char ch;
    > int i =2;
    > for (ch=0;ch<128;ch++)
    > i+=2;
    > printf("%d",i);
    > }
    > i wrote the answer 256 will be printed.
    > But our instructor told me that it will be infinite loop.
    > Is that right, I am not sure of the answer.


    Your instructor may have been right. It all depends on CHAR_MAX, which may
    be 127 if char is signed. If this is the case, ch will never be >= 128,
    and the loop will never end. If CHAR_MAX is greater than 127 (because it's
    unsigned, or because char has more than 8 value bits), then it may print
    258 (and will for sure if you print a newline or flush stdout).

    --
    int main(void){int putchar(int),i=0;unsigned long t=500555079,n[]={t
    ,159418370,88921539,286883974,80500161,0};while(n)putchar(*(!(t&1
    )+!(t||!++i)+"# \n")),(t&&1+(t>>=i-~-i))||(t=n^n[i-1]);return 0;}
    Pieter Droogendijk, May 24, 2004
    #3
  4. On Mon, 24 May 2004, bnp wrote:
    >
    > I took a test on C.
    > there was an objective question for program output type.
    > following is the program:
    >
    >


    Good style dictates the inclusion of <stdio.h> (see errors regarding
    'printf' below).

    > main()


    _int_ main() required for C99; _int_ main(_void_) preferred in both
    C89 and C99. (Where _this_ indicates emphasis, not literal underscores.)

    > {
    > char ch;


    Lack of indentation is a bad thing and should be avoided, especially
    on Usenet and on school tests. Also, everywhere else.

    > int i =2;
    > for (ch=0;ch<128;ch++)


    Non-strict-conformance: program behavior depends on signedness of
    plain char.
    Possible undefined behavior: If char is signed and has eight bits,
    signed integer overflow will occur.

    > i+=2;
    > printf("%d",i);


    Possible linker error: 'printf' undefined.
    Undefined behavior: variadic function 'printf' called without
    prototype in scope.
    Constraint violation (is that correct?): program output ends
    without terminating newline '\n'.

    > }
    > i wrote the answer 256 will be printed.
    > But our instructor told me that it will be infinite loop.
    > Is that right, I am not sure of the answer.


    Yes, you are both "right." Only the program is wrong.

    -Arthur
    Arthur J. O'Dwyer, May 24, 2004
    #4
  5. bnp

    CBFalconer Guest

    Pieter Droogendijk wrote:
    > On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:
    >
    >> I took a test on C.
    >> there was an objective question for program output type.
    >> following is the program:
    >>
    >> main()

    >
    > int main () or int main (void) is preferred.
    >
    >> {

    >
    > Proper indentation is a Good Thing(tm), even for trivial examples
    > such as this.
    >
    >> char ch;
    >> int i =2;
    >> for (ch=0;ch<128;ch++)
    >> i+=2;
    >> printf("%d",i);
    >> }
    >> i wrote the answer 256 will be printed.
    >> But our instructor told me that it will be infinite loop.
    >> Is that right, I am not sure of the answer.

    >
    > Your instructor may have been right. It all depends on CHAR_MAX,
    > which may be 127 if char is signed. If this is the case, ch will
    > never be >= 128, and the loop will never end. If CHAR_MAX is
    > greater than 127 (because it's unsigned, or because char has
    > more than 8 value bits), then it may print 258 (and will for
    > sure if you print a newline or flush stdout).


    No, in that (signed) case you will overflow ch, and behaviour
    becomes undefined. So it may well print "the instructor is full
    of it" or do anything else.

    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    CBFalconer, May 24, 2004
    #5
  6. bnp

    buda Guest

    So overflow is undefined? I thought that the "overflowed bit" gets discarded
    and you end up with the "next" number, which in this case might be -128 (if
    char is 8 bits signed, then gets to 127 which is 0111 1111, thus adding one
    in binary will make it 1000 0000 which translates into -128). I actually
    expect this to be "not defined" by the standard, but this is the behavior on
    most (if not all) machines I have seen.

    "CBFalconer" <> wrote in message
    news:...
    > Pieter Droogendijk wrote:
    > > On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:
    > >
    > >> I took a test on C.
    > >> there was an objective question for program output type.
    > >> following is the program:
    > >>
    > >> main()

    > >
    > > int main () or int main (void) is preferred.
    > >
    > >> {

    > >
    > > Proper indentation is a Good Thing(tm), even for trivial examples
    > > such as this.
    > >
    > >> char ch;
    > >> int i =2;
    > >> for (ch=0;ch<128;ch++)
    > >> i+=2;
    > >> printf("%d",i);
    > >> }
    > >> i wrote the answer 256 will be printed.
    > >> But our instructor told me that it will be infinite loop.
    > >> Is that right, I am not sure of the answer.

    > >
    > > Your instructor may have been right. It all depends on CHAR_MAX,
    > > which may be 127 if char is signed. If this is the case, ch will
    > > never be >= 128, and the loop will never end. If CHAR_MAX is
    > > greater than 127 (because it's unsigned, or because char has
    > > more than 8 value bits), then it may print 258 (and will for
    > > sure if you print a newline or flush stdout).

    >
    > No, in that (signed) case you will overflow ch, and behaviour
    > becomes undefined. So it may well print "the instructor is full
    > of it" or do anything else.
    >
    > --
    > A: Because it fouls the order in which people normally read text.
    > Q: Why is top-posting such a bad thing?
    > A: Top-posting.
    > Q: What is the most annoying thing on usenet and in e-mail?
    >
    >
    buda, May 24, 2004
    #6
  7. bnp

    Dan Pop Guest

    In <> Leor Zolman <> writes:

    >On 24 May 2004 04:20:00 -0700, (bnp) wrote:
    >
    >>I took a test on C.
    >>there was an objective question for program output type.
    >>following is the program:
    >>
    >>main()
    >>{
    >>char ch;
    >>int i =2;
    >>for (ch=0;ch<128;ch++)
    >>i+=2;
    >>printf("%d",i);
    >>}
    >>i wrote the answer 256 will be printed.
    >>But our instructor told me that it will be infinite loop.
    >>Is that right, I am not sure of the answer.

    >
    >Kinda tricky.


    Not really: the code invokes undefined behaviour at least once, by calling
    printf without a proper declaration in scope, so it is not even worth
    analysing it: anything can legally happen.

    >First of all, the default "signedness" of the char type is
    >platform-dependent. If it is 8 bits and "signed", as is the default on
    >typical PC-based platforms, then this does indeed go into an infinite loop.


    Can we have a chapter and verse for that? I naively thought that signed
    overflow results in undefined behaviour...

    >In that case, the range of values for an 8-bit char is -128 to +127.


    Can we have a chapter and verse for that? I naively thought that the
    standard only guaranteed -127 to 127 and that sign-magnitude and one's
    complement implementations are perfectly OK...

    >It will always be less than +128.


    True, but by the time it makes the transition from 127 to whatever value
    (if any), anything can happen... including getting out of the loop.

    >If the default for chars is unsigned, then the program output is 258 [I
    >didn't figure it out, I just ran it ;-) ]


    Maybe, maybe not. As the last line of output is not newline terminated,
    there is no guarantee that the program will produce any output at all
    (it's an implementation-defined feature).

    Whoever wrote this test expecting another answer than "undefined
    behaviour" should better start learning C...

    Here's a properly rewritten version of this test:

    Assuming 8-bit bytes, what is the output of the following program?

    #include <stdio.h>

    int main()
    {
    unsigned char ch;
    unsigned int i = 2;

    for (ch = 0; ch < 256; ch++) i += 2;
    printf("%u\n", i);
    return 0;
    }

    Note that if i is plain int, signed overflow will occur inside the
    infinite loop, and all the bets are off, again.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, May 24, 2004
    #7
  8. bnp

    Ralmin Guest

    "buda" <> wrote:
    > So overflow is undefined? I thought that the "overflowed bit" gets
    > discarded and you end up with the "next" number, which in this case
    > might be -128 (if char is 8 bits signed, then gets to 127 which is
    > 0111 1111, thus adding one in binary will make it 1000 0000 which
    > translates into -128). I actually expect this to be "not defined"
    > by the standard, but this is the behavior on most (if not all)
    > machines I have seen.


    Yes, signed integer overflow is undefined behaviour in C. Some machines trap
    on overflow, others discard the overflow like you describe. In that case it
    depends on whether the signed integer is using 2's complement, 1's
    complement or the signed magnitude system.

    In 8-bit 2's complement, 1000 0000 is -128
    In 8-bit 1's complement, 1000 0000 is -127
    In 8-bit signed magnitude, 1000 0000 is negative zero, which might be a
    valid result, or might itself be a trap representation.

    There might even be more wacky forms of undefined behaviour that occur on
    overflow.

    --
    Simon.
    Ralmin, May 24, 2004
    #8
  9. "Arthur J. O'Dwyer" <> writes:

    > On Mon, 24 May 2004, bnp wrote:
    >
    >> printf("%d",i);

    >
    > Constraint violation (is that correct?): program output ends
    > without terminating newline '\n'.


    Implementation-defined and possibly undefined behavior. See 7.19.2#2:
    "A text stream is an ordered sequence of characters composed into lines,
    each line consisting of zero or more characters plus a terminating new-
    line character. Whether the last line requires a terminating new-line
    character is implementation-defined. [...]"

    Martin


    --
    ,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
    / ,- ) http://www.zero-based.org/ ((_/)o o(\_))
    \ `-' `-'(. .)`-'
    `-. Debian, a variant of the GNU operating system. \_/
    Martin Dickopp, May 24, 2004
    #9
  10. bnp

    buda Guest

    "Ralmin" <> wrote in message
    news:...
    > Yes, signed integer overflow is undefined behaviour in C. Some machines

    trap
    > on overflow, others discard the overflow like you describe. In that case

    it
    > depends on whether the signed integer is using 2's complement, 1's
    > complement or the signed magnitude system.
    >
    > In 8-bit 2's complement, 1000 0000 is -128
    > In 8-bit 1's complement, 1000 0000 is -127
    > In 8-bit signed magnitude, 1000 0000 is negative zero, which might be a
    > valid result, or might itself be a trap representation.
    >
    > There might even be more wacky forms of undefined behaviour that occur on
    > overflow.
    >
    > --
    > Simon.
    >


    Thanks for the answer.
    buda, May 24, 2004
    #10
  11. bnp

    CBFalconer Guest

    *** Rude top-posting fixed ***

    buda wrote:
    > "CBFalconer" <> wrote in message
    >> Pieter Droogendijk wrote:
    >>> On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:
    >>>
    >>>> I took a test on C.
    >>>> there was an objective question for program output type.
    >>>> following is the program:
    >>>>
    >>>> main()
    >>>
    >>> int main () or int main (void) is preferred.
    >>>
    >>>> {
    >>>
    >>> Proper indentation is a Good Thing(tm), even for trivial examples
    >>> such as this.
    >>>
    >>>> char ch;
    >>>> int i =2;
    >>>> for (ch=0;ch<128;ch++)
    >>>> i+=2;
    >>>> printf("%d",i);
    >>>> }
    >>>> i wrote the answer 256 will be printed.
    >>>> But our instructor told me that it will be infinite loop.
    >>>> Is that right, I am not sure of the answer.
    >>>
    >>> Your instructor may have been right. It all depends on CHAR_MAX,
    >>> which may be 127 if char is signed. If this is the case, ch will
    >>> never be >= 128, and the loop will never end. If CHAR_MAX is
    >>> greater than 127 (because it's unsigned, or because char has
    >>> more than 8 value bits), then it may print 258 (and will for
    >>> sure if you print a newline or flush stdout).

    >>
    >> No, in that (signed) case you will overflow ch, and behaviour
    >> becomes undefined. So it may well print "the instructor is full
    >> of it" or do anything else.

    >
    > So overflow is undefined? I thought that the "overflowed bit" gets
    > discarded and you end up with the "next" number, which in this
    > case might be -128 (if char is 8 bits signed, then gets to 127
    > which is 0111 1111, thus adding one in binary will make it 1000
    > 0000 which translates into -128). I actually expect this to be
    > "not defined" by the standard, but this is the behavior on most
    > (if not all) machines I have seen.


    Undefined for signed quantities. Defined for unsigned ones. This
    is all spelled out in the standard, so there is no need to guess.
    Your description is only one form undefined behaviour may take.
    Undefined behaviour could also be for the machine to post spam
    offering large rewards for the assasination of top-posters.

    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    CBFalconer, May 24, 2004
    #11
  12. In 'comp.lang.c', (bnp) wrote:

    > I took a test on C.
    > there was an objective question for program output type.
    > following is the program:


    This program invokes an undefined behaviour. For many reasons, its output is
    not predictable.

    Here are my comments.

    /* -ed- Missing fot printf() (mandatory) */
    #include <stdio.h>

    int main ()
    {
    /* -ed- 128 is not guaranteed to fit into a char.
    * It fits into an unsigned char.
    */
    unsigned char ch;
    int i = 2;

    for (ch = 0; ch < 128; ch++)
    {
    i += 2;
    }
    /* -ed- Curly brackets added for safety and look. */

    /* -ed- '\n' added to be sure to see the output.*/
    printf ("%d\n", i);

    /* -ed- Because main() returns an int */
    return 0;
    }

    Once fixed, the result is 2 + 128 * 2 = 258.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
    Emmanuel Delahaye, May 24, 2004
    #12
  13. bnp

    Leor Zolman Guest

    On 24 May 2004 17:33:21 GMT, (Dan Pop) wrote:

    >In <> Leor Zolman <> writes:
    >
    >>On 24 May 2004 04:20:00 -0700, (bnp) wrote:
    >>
    >>>I took a test on C.
    >>>there was an objective question for program output type.
    >>>following is the program:
    >>>
    >>>main()
    >>>{
    >>>char ch;
    >>>int i =2;
    >>>for (ch=0;ch<128;ch++)
    >>>i+=2;
    >>>printf("%d",i);
    >>>}
    >>>i wrote the answer 256 will be printed.
    >>>But our instructor told me that it will be infinite loop.
    >>>Is that right, I am not sure of the answer.

    >>
    >>Kinda tricky.

    >
    >Not really: the code invokes undefined behaviour at least once, by calling
    >printf without a proper declaration in scope, so it is not even worth
    >analysing it: anything can legally happen.


    Sure, technically this (and all the rest of it) may be correct. I responded
    from an exam question standpoint: "What will it do?" (IOW, "What does it do
    for the instructor?"), rather than "What does the Standard say?" (applying
    the usual rigor expected for answers to general questions in this group). I
    should have prefaced my response accordingly.
    -leor

    --
    Leor Zolman --- BD Software --- www.bdsoft.com
    On-Site Training in C/C++, Java, Perl and Unix
    C++ users: download BD Software's free STL Error Message Decryptor at:
    www.bdsoft.com/tools/stlfilt.html
    Leor Zolman, May 24, 2004
    #13
  14. On Mon, 24 May 2004, Martin Dickopp wrote:
    >
    > "Arthur J. O'Dwyer" <> writes:
    > >
    > > Constraint violation (is that correct?): program output ends
    > > without terminating newline '\n'.

    >
    > Implementation-defined and possibly undefined behavior. See 7.19.2#2:
    > "A text stream is an ordered sequence of characters composed into lines,
    > each line consisting of zero or more characters plus a terminating new-
    > line character. Whether the last line requires a terminating new-line
    > character is implementation-defined. [...]"


    Thanks for the quote. But what's the quote that tells us that if
    we fail to do something that is, quote, "required," that we invoke
    undefined behavior? I don't see anything relevant upon a quick scan
    of Appendix J, either...

    -Arthur
    Arthur J. O'Dwyer, May 24, 2004
    #14
  15. On Mon, 24 May 2004, Leor Zolman wrote:
    >
    > On 24 May 2004 17:33:21 GMT, (Dan Pop) wrote:
    > >Leor Zolman <> writes:
    > >>On 24 May 2004 04:20:00 -0700, (bnp) wrote:
    > >>
    > >>>I took a test on C.
    > >>>there was an objective question for program output type.
    > >>>following is the program:

    <snip>
    > >>>i wrote the answer 256 will be printed.
    > >>>But our instructor told me that it will be infinite loop.
    > >>
    > >>Kinda tricky.

    > >
    > >Not really: the code invokes undefined behaviour


    > Sure, technically this (and all the rest of it) may be correct. I responded
    > from an exam question standpoint: "What will it do?" (IOW, "What does it do
    > for the instructor?"), rather than "What does the Standard say?" (applying
    > the usual rigor expected for answers to general questions in this group). I
    > should have prefaced my response accordingly.


    However --- and I speak from personal experience at high school and
    college levels --- it is almost always easier to prove to the instructor
    that the code is faulty, than it is to try to guess what the instructor
    was thinking.

    In this case, the OP had two choices: write down what he thought the
    instructor wanted, or raise his hand and say "Excuse me, there seems to
    be a bug in this program... could you clarify the problem, please?"
    Best case, the instructor realizes the problem is unsolvable and gives
    everybody in the class extra credit. Worst case, the instructor says,
    "char is unsigned and <stdio.h> is included," and the OP is back where
    he started.
    The OP had better have hoped for the best-case scenario, since his
    guess turned out to be wrong. By drawing attention to the bugs in
    the program, he would have maximized his chances of getting credit for
    the question.

    Again, I speak from experience, and am not being pedantic merely
    for pedantry's sake. If the OP can learn to recognize common errors
    in C programs, then he stands to benefit in the short term. (In the
    long term, he won't be dealing with contrived C programs anymore, and
    he'll have to learn common *correct* ways to *write* C programs. But
    this is a good way to start. :)

    -Arthur
    Arthur J. O'Dwyer, May 24, 2004
    #15
  16. bnp

    Old Wolf Guest

    (bnp) wrote:
    > I took a test on C.
    > there was an objective question for program output type.
    > following is the program:
    >
    > main()
    > {
    > char ch;
    > int i =2;
    > for (ch=0;ch<128;ch++)
    > i+=2;
    > printf("%d",i);
    > }
    > i wrote the answer 256 will be printed.
    > But our instructor told me that it will be infinite loop.
    > Is that right, I am not sure of the answer.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Good work. Since the behaviour is undefined (if CHAR_MAX is 127),
    it is not possible to be sure of the answer.
    Old Wolf, May 24, 2004
    #16
  17. "Arthur J. O'Dwyer" <> writes:

    > On Mon, 24 May 2004, Martin Dickopp wrote:
    >>
    >> "Arthur J. O'Dwyer" <> writes:
    >> >
    >> > Constraint violation (is that correct?): program output ends
    >> > without terminating newline '\n'.

    >>
    >> Implementation-defined and possibly undefined behavior. See 7.19.2#2:
    >> "A text stream is an ordered sequence of characters composed into lines,
    >> each line consisting of zero or more characters plus a terminating new-
    >> line character. Whether the last line requires a terminating new-line
    >> character is implementation-defined. [...]"

    >
    > Thanks for the quote. But what's the quote that tells us that if
    > we fail to do something that is, quote, "required," that we invoke
    > undefined behavior?


    Assuming the case that the implementation requires a terminating newline
    character, the standard doesn't say what should happen if there is no
    such character. Therefore, the behavior is undefined since it is not
    explicitly defined, as per 4#2: "[...] Undefined behavior is otherwise
    indicated in this International Standard [...] by the omission of any
    explicit definition of behavior. [...]"

    (That's at least how I understand 7.19.2#2.)

    AFAIKT, the term "require" isn't explicitly defined in the standard, so
    I understand it in its normal English sense (i.e. unlike a "constraint
    violation", a "requirement violation" has no special meaning).

    Martin


    --
    ,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
    / ,- ) http://www.zero-based.org/ ((_/)o o(\_))
    \ `-' `-'(. .)`-'
    `-. Debian, a variant of the GNU operating system. \_/
    Martin Dickopp, May 24, 2004
    #17
  18. bnp

    Leor Zolman Guest

    On Mon, 24 May 2004 17:01:45 -0400 (EDT), "Arthur J. O'Dwyer"
    <> wrote:

    >
    >On Mon, 24 May 2004, Leor Zolman wrote:
    >>
    >> On 24 May 2004 17:33:21 GMT, (Dan Pop) wrote:
    >> >Leor Zolman <> writes:
    >> >>On 24 May 2004 04:20:00 -0700, (bnp) wrote:
    >> >>
    >> >>>I took a test on C.
    >> >>>there was an objective question for program output type.
    >> >>>following is the program:

    ><snip>
    >> >>>i wrote the answer 256 will be printed.
    >> >>>But our instructor told me that it will be infinite loop.
    >> >>
    >> >>Kinda tricky.
    >> >
    >> >Not really: the code invokes undefined behaviour

    >
    >> Sure, technically this (and all the rest of it) may be correct. I responded
    >> from an exam question standpoint: "What will it do?" (IOW, "What does it do
    >> for the instructor?"), rather than "What does the Standard say?" (applying
    >> the usual rigor expected for answers to general questions in this group). I
    >> should have prefaced my response accordingly.

    >
    > However --- and I speak from personal experience at high school and
    >college levels --- it is almost always easier to prove to the instructor
    >that the code is faulty, than it is to try to guess what the instructor
    >was thinking.


    <OT>
    I'm tempted to change the subject now to "[OT]: Challenging instructors" or
    something. This could be an interesting topic, but it seems pretty OT.

    >
    > In this case, the OP had two choices: write down what he thought the
    >instructor wanted, or raise his hand and say "Excuse me, there seems to
    >be a bug in this program... could you clarify the problem, please?"


    If the OP knew there was a bug. But the question he posted was about what
    the program would do. How many students, in that position, and with an
    instructor who writes exam questions like /that/ (the declaration of main
    was, IMO, particularly egregious), would be likely to detect a "flaw" in
    the question? To be able to ask, you have to have a handle on what to ask.
    From what I see, the most likely question to come up in this example would
    have been regarding the signed-ness of char. I would /hope/ the fact that
    this is implementation-dependent would have been discussed in class, but I
    wouldn't bet on it. Given that, I'd put the chances near zero that there
    was any discussion in that course about how not including <stdio.h> invokes
    UB with printf (I can't even say I fully understand that myself right now),
    or what happens when the last line of output is unterminated. Unless they'd
    had access to a C99 compiler in strict mode, I doubt these issues would
    have shown up even if they'd been written into programs.

    I get the feeling that if someone /did/ bring up the stdio.h or line
    termination issue, the instructor either wouldn't know what the student was
    talking about, or brush it off with a roll of the eyes and a "Just
    assume...."

    >Best case, the instructor realizes the problem is unsolvable and gives
    >everybody in the class extra credit. Worst case, the instructor says,
    >"char is unsigned and <stdio.h> is included," and the OP is back where
    >he started.
    > The OP had better have hoped for the best-case scenario, since his
    >guess turned out to be wrong. By drawing attention to the bugs in
    >the program, he would have maximized his chances of getting credit for
    >the question.


    A good instructor loves to be corrected and/or challenged by students, but
    I've (unfortunately) also seen some that it would have been a grievous
    tactical error to point out some of those issues to. Unfortunately, those
    latter types often tend to have a disproportional amount of political clout
    in the learning institution, for some Godforsaken reason...

    >
    > Again, I speak from experience, and am not being pedantic merely
    >for pedantry's sake. If the OP can learn to recognize common errors
    >in C programs, then he stands to benefit in the short term. (In the
    >long term, he won't be dealing with contrived C programs anymore, and
    >he'll have to learn common *correct* ways to *write* C programs. But
    >this is a good way to start. :)


    Reading this newsgroup could definitely accelerate one's coming-of-age as a
    C programmer (though perhaps not as much as posting and then being brave
    enough to actually read the responses). At the beginning level, however, I
    suspect most students' neurons are busy enough trying to remember how to
    define and use pointers, stay within array bounds, understand flow control,
    and (with the especially clueless instructors) memorizing the precedence
    table, to have the capacity left to pursue distinctions of UB between
    signed and unsigned integral values. The ones who do, are probably destined
    to be future regulars in this group ;-)
    -leor
    </OT>

    >
    >-Arthur


    --
    Leor Zolman --- BD Software --- www.bdsoft.com
    On-Site Training in C/C++, Java, Perl and Unix
    C++ users: download BD Software's free STL Error Message Decryptor at:
    www.bdsoft.com/tools/stlfilt.html
    Leor Zolman, May 25, 2004
    #18
  19. bnp

    Jack Klein Guest

    On Tue, 25 May 2004 00:09:35 +0200, Martin Dickopp
    <> wrote in comp.lang.c:

    > "Arthur J. O'Dwyer" <> writes:
    >
    > > On Mon, 24 May 2004, Martin Dickopp wrote:
    > >>
    > >> "Arthur J. O'Dwyer" <> writes:
    > >> >
    > >> > Constraint violation (is that correct?): program output ends
    > >> > without terminating newline '\n'.
    > >>
    > >> Implementation-defined and possibly undefined behavior. See 7.19.2#2:
    > >> "A text stream is an ordered sequence of characters composed into lines,
    > >> each line consisting of zero or more characters plus a terminating new-
    > >> line character. Whether the last line requires a terminating new-line
    > >> character is implementation-defined. [...]"

    > >
    > > Thanks for the quote. But what's the quote that tells us that if
    > > we fail to do something that is, quote, "required," that we invoke
    > > undefined behavior?

    >
    > Assuming the case that the implementation requires a terminating newline
    > character, the standard doesn't say what should happen if there is no
    > such character. Therefore, the behavior is undefined since it is not
    > explicitly defined, as per 4#2: "[...] Undefined behavior is otherwise
    > indicated in this International Standard [...] by the omission of any
    > explicit definition of behavior. [...]"
    >
    > (That's at least how I understand 7.19.2#2.)
    >
    > AFAIKT, the term "require" isn't explicitly defined in the standard, so
    > I understand it in its normal English sense (i.e. unlike a "constraint
    > violation", a "requirement violation" has no special meaning).
    >
    > Martin


    Anything that the standard specifies as "implementation-defined", a
    term which is precisely defined in the standard, cannot result in
    undefined behavior.

    The implementation is required to select one of the available choices,
    in this case either the last line appears in the output stream if no
    terminating new-line is present, or it does not. And the
    implementation is required to document its choice, therefore defining
    the behavior for that implementation.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    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, May 25, 2004
    #19
  20. Jack Klein <> writes:

    > On Tue, 25 May 2004 00:09:35 +0200, Martin Dickopp
    > <> wrote in comp.lang.c:
    >
    >> "Arthur J. O'Dwyer" <> writes:
    >>
    >> > On Mon, 24 May 2004, Martin Dickopp wrote:
    >> >>
    >> >> "Arthur J. O'Dwyer" <> writes:
    >> >> >
    >> >> > Constraint violation (is that correct?): program output ends
    >> >> > without terminating newline '\n'.
    >> >>
    >> >> Implementation-defined and possibly undefined behavior. See 7.19.2#2:
    >> >> "A text stream is an ordered sequence of characters composed into lines,
    >> >> each line consisting of zero or more characters plus a terminating new-
    >> >> line character. Whether the last line requires a terminating new-line
    >> >> character is implementation-defined. [...]"
    >> >
    >> > Thanks for the quote. But what's the quote that tells us that if
    >> > we fail to do something that is, quote, "required," that we invoke
    >> > undefined behavior?

    >>
    >> Assuming the case that the implementation requires a terminating newline
    >> character, the standard doesn't say what should happen if there is no
    >> such character. Therefore, the behavior is undefined since it is not
    >> explicitly defined, as per 4#2: "[...] Undefined behavior is otherwise
    >> indicated in this International Standard [...] by the omission of any
    >> explicit definition of behavior. [...]"
    >>
    >> (That's at least how I understand 7.19.2#2.)
    >>
    >> AFAIKT, the term "require" isn't explicitly defined in the standard, so
    >> I understand it in its normal English sense (i.e. unlike a "constraint
    >> violation", a "requirement violation" has no special meaning).

    >
    > Anything that the standard specifies as "implementation-defined", a
    > term which is precisely defined in the standard, cannot result in
    > undefined behavior.
    >
    > The implementation is required to select one of the available choices,
    > in this case either the last line appears in the output stream if no
    > terminating new-line is present, or it does not. And the
    > implementation is required to document its choice, therefore defining
    > the behavior for that implementation.


    Let's assume an implementation that has documented that the last line
    requires a terminating newline character. On such an implementation,
    the following program is not correct:

    #include <stdio.h>
    int main (void) { putchar ('x'); return 0; }

    I would have thought the behavior of the program is undefined on such an
    implementation. If that is not the case, what is the behavior of the
    above program on such an implementation?

    Martin


    --
    ,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
    / ,- ) http://www.zero-based.org/ ((_/)o o(\_))
    \ `-' `-'(. .)`-'
    `-. Debian, a variant of the GNU operating system. \_/
    Martin Dickopp, May 25, 2004
    #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. John Bentley

    Output / Debug window output bug?

    John Bentley, Sep 10, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    591
    John Bentley
    Sep 10, 2003
  2. chuck amadi
    Replies:
    1
    Views:
    489
    Larry Bates
    Jun 23, 2004
  3. Puneet
    Replies:
    16
    Views:
    1,126
    Daniel Vallstrom
    Mar 20, 2005
  4. Paul
    Replies:
    1
    Views:
    430
  5. jmr
    Replies:
    2
    Views:
    335
Loading...

Share This Page