Why does the output jam in the following case - Unix

This is a discussion on Why does the output jam in the following case - Unix ; [cdalten@localhost oakland]$ more config printerserver blade printer phaser860 [cdalten@localhost oakland]$ more out.c #include #include #include #include #define INPUT "/home/cdalten/oakland/config" #define BUF 5 int main(void) { int fd; char line[BUF]; int n; if((fd = open(INPUT, O_RDONLY)) fprintf(stderr, "can't open file\n"); exit(1); ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Why does the output jam in the following case

  1. Why does the output jam in the following case

    [cdalten@localhost oakland]$ more config
    printerserver blade
    printer phaser860
    [cdalten@localhost oakland]$ more out.c
    #include
    #include
    #include
    #include

    #define INPUT "/home/cdalten/oakland/config"

    #define BUF 5
    int main(void)
    {
    int fd;
    char line[BUF];
    int n;

    if((fd = open(INPUT, O_RDONLY)) < 0){
    fprintf(stderr, "can't open file\n");
    exit(1);
    }

    while( (n = read(fd, line, BUF)) > 0 ){
    line[n]=0;
    printf("%s\n", line);
    }

    close(fd);
    return 0;
    }
    [cdalten@localhost oakland]$ ./out
    print

    Why does the output just hang? Am I clobbering the memory?

  2. Re: Why does the output jam in the following case

    In comp.unix.programmer K-mart Cashier wrote:
    > [cdalten@localhost oakland]$ more config
    > printerserver blade
    > printer phaser860
    > [cdalten@localhost oakland]$ more out.c
    > #include
    > #include
    > #include
    > #include


    > #define INPUT "/home/cdalten/oakland/config"


    > #define BUF 5
    > int main(void)
    > {
    > int fd;
    > char line[BUF];
    > int n;


    > if((fd = open(INPUT, O_RDONLY)) < 0){
    > fprintf(stderr, "can't open file\n");
    > exit(1);
    > }


    > while( (n = read(fd, line, BUF)) > 0 ){
    > line[n]=0;
    > printf("%s\n", line);
    > }


    > close(fd);
    > return 0;
    > }
    > [cdalten@localhost oakland]$ ./out
    > print


    > Why does the output just hang? Am I clobbering the memory?


    I don't know about the first question but "yes" is the answer
    to the second one. 'line' has room for 5 chars and you tell
    read() to get you 5. If it does read 5 chars you append a 6th
    character ('\0') to the array that has only 5. You're rather
    likely writing over the variable 'n' or 'fd', which could re-
    sult in the program hanging (if e.g. 'fd' gets set to 0 by
    writing past the end of the array then the program will try
    to read from stdin, which may then look like it's hanging).
    Just make 'line' have one more element and check what happens.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

  3. Re: Why does the output jam in the following case

    K-mart Cashier said:

    > [cdalten@localhost oakland]$ more config
    > printerserver blade
    > printer phaser860
    > [cdalten@localhost oakland]$ more out.c
    > #include
    > #include
    > #include
    > #include
    >
    > #define INPUT "/home/cdalten/oakland/config"
    >
    > #define BUF 5
    > int main(void)
    > {
    > int fd;
    > char line[BUF];


    BUF is 5, so line has five elements. They are:

    line[0] (that's one);
    line[1] (two);
    line[2] (that's the third);
    line[3] (and the fourth);
    line[4] (the fifth and LAST).

    > int n;
    >
    > if((fd = open(INPUT, O_RDONLY)) < 0){
    > fprintf(stderr, "can't open file\n");
    > exit(1);
    > }
    >
    > while( (n = read(fd, line, BUF)) > 0 ){


    What is n at this point? If you don't know, find out. Use gdb or add a
    printf or something.

    > line[n]=0;


    The question you got to ask yourself is - are you allowed to write to
    line[n]?

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  4. Re: Why does the output jam in the following case

    Jens Thoms Toerring said:



    > Just make 'line' have one more element and check what happens.


    Whether this works will depend on how he does it. If he simply changes:

    #define BUF 5

    to

    #define BUF 6

    it isn't going to fix the problem.

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  5. Re: Why does the output jam in the following case

    K-mart Cashier writes:

    > [cdalten@localhost oakland]$ more config
    > printerserver blade
    > printer phaser860
    > [cdalten@localhost oakland]$ more out.c
    > #include
    > #include
    > #include
    > #include
    >
    > #define INPUT "/home/cdalten/oakland/config"
    >
    > #define BUF 5
    > int main(void)
    > {
    > int fd;
    > char line[BUF];
    > int n;
    >
    > if((fd = open(INPUT, O_RDONLY)) < 0){
    > fprintf(stderr, "can't open file\n");
    > exit(1);
    > }
    >
    > while( (n = read(fd, line, BUF)) > 0 ){
    > line[n]=0;
    > printf("%s\n", line);
    > }
    >
    > close(fd);
    > return 0;
    > }
    > [cdalten@localhost oakland]$ ./out
    > print
    >
    > Why does the output just hang? Am I clobbering the memory?


    Yes. line valid indexes run from 0 to 4 inclusive. line[n] is most
    often an out-of-bounds write.

    --
    Ben.

  6. Re: Why does the output jam in the following case

    jt@toerring.de (Jens Thoms Toerring) writes:
    > In comp.unix.programmer K-mart Cashier wrote:


    [...]

    >> char line[BUF];


    [...]

    >
    >> while( (n = read(fd, line, BUF)) > 0 ){
    >> line[n]=0;


    [...]

    >> Why does the output just hang? Am I clobbering the memory?

    >
    > I don't know about the first question but "yes" is the answer
    > to the second one. 'line' has room for 5 chars and you tell
    > read() to get you 5. If it does read 5 chars you append a 6th
    > character ('\0') to the array that has only 5. You're rather
    > likely writing over the variable 'n' or 'fd', which could re-
    > sult in the program hanging (if e.g. 'fd' gets set to 0 by
    > writing past the end of the array then the program will try
    > to read from stdin, which may then look like it's hanging).


    That's exactly what is happening in this case. It is possible to
    determine this with a debugger, but strace is already sufficient:

    [rw@fever]/tmp $strace ./a.out
    execve("./a.out", ["./a.out"], [/* 25 vars */]) = 0
    uname({sys="Linux", node="fever", ...}) = 0

    [...]

    open("/var/log/syslog", O_RDONLY) = 3
    read(3, "Aug ", 5) = 5
    fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd2000
    write(1, "Aug \n", 6Aug
    ) = 6
    read(0,

  7. Re: Why does the output jam in the following case

    Richard Heathfield writes:
    > Jens Thoms Toerring said:
    >
    >
    >
    >> Just make 'line' have one more element and check what happens.

    >
    > Whether this works will depend on how he does it. If he simply changes:
    >
    > #define BUF 5
    >
    > to
    >
    > #define BUF 6
    >
    > it isn't going to fix the problem.


    #defining BUF n does not result in line[BUF] being declared to have
    'one more element' than BUF.


  8. Re: Why does the output jam in the following case

    Rainer Weikusat said:

    > Richard Heathfield writes:
    >> Jens Thoms Toerring said:
    >>
    >>
    >>
    >>> Just make 'line' have one more element and check what happens.

    >>
    >> Whether this works will depend on how he does it. If he simply changes:
    >>
    >> #define BUF 5
    >>
    >> to
    >>
    >> #define BUF 6
    >>
    >> it isn't going to fix the problem.

    >
    > #defining BUF n does not result in line[BUF] being declared to have
    > 'one more element' than BUF.


    No, but it does result in 'line' having one more element (it had five, but
    now it has six, and six is one more than five). My point was that the
    suggested fix was ambiguous.

    Changing the definition of line so that it has [BUF + 1] elements, whilst
    leaving the in-loop assignment intact, is presumably what Jens actually
    meant.

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  9. Re: Why does the output jam in the following case

    Richard Heathfield writes:
    > Rainer Weikusat said:
    >
    >> Richard Heathfield writes:
    >>> Jens Thoms Toerring said:
    >>>
    >>>
    >>>
    >>>> Just make 'line' have one more element and check what happens.
    >>>
    >>> Whether this works will depend on how he does it. If he simply changes:
    >>>
    >>> #define BUF 5
    >>>
    >>> to
    >>>
    >>> #define BUF 6
    >>>
    >>> it isn't going to fix the problem.

    >>
    >> #defining BUF n does not result in line[BUF] being declared to have
    >> 'one more element' than BUF.

    >
    > No, but it does result in 'line' having one more element


    No, it doesn't. The size of line was BUF before the change and it is it
    still BUF after the change.

  10. Re: Why does the output jam in the following case

    Rainer Weikusat said:

    > Richard Heathfield writes:
    >> Rainer Weikusat said:
    >>


    >>>
    >>> #defining BUF n does not result in line[BUF] being declared to have
    >>> 'one more element' than BUF.

    >>
    >> No, but it does result in 'line' having one more element


    [Selective snippage has damaged my intended meaning, which was that with
    BUF changed from 5 to 6, the 'line' array had six elements instead of
    five, hence 'one more element'.]

    > No, it doesn't.


    Yes, it does. See above.

    > The size of line was BUF before the change and it is it
    > still BUF after the change.


    True, but only semi-relevant. You are demonstrating with a certain degree
    of skill and obstinacy how easy it is to read an ambiguous statement in
    /one/ way, whilst ignoring the other way completely. The original
    statement /was/ ambiguous, however, and the fact that you are only
    prepared to see one meaning in it does not mean that other meanings cannot
    or do not exist.

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  11. Re: Why does the output jam in the following case

    Richard Heathfield writes:
    > Rainer Weikusat said:
    >
    >> Richard Heathfield writes:
    >>> Rainer Weikusat said:
    >>>

    >
    >>>>
    >>>> #defining BUF n does not result in line[BUF] being declared to have
    >>>> 'one more element' than BUF.
    >>>
    >>> No, but it does result in 'line' having one more element

    >
    > [Selective snippage has damaged my intended meaning, which was that with
    > BUF changed from 5 to 6, the 'line' array had six elements instead of
    > five, hence 'one more element'.]
    >
    >> No, it doesn't.

    >
    > Yes, it does. See above.


    The size if line is BUF. No change of the definition of BUF is ever
    going to change that.

  12. Re: Why does the output jam in the following case

    Rainer Weikusat said:

    > Richard Heathfield writes:
    >> Rainer Weikusat said:
    >>
    >>> Richard Heathfield writes:
    >>>> Rainer Weikusat said:
    >>>>

    >>
    >>>>>
    >>>>> #defining BUF n does not result in line[BUF] being declared to have
    >>>>> 'one more element' than BUF.
    >>>>
    >>>> No, but it does result in 'line' having one more element

    >>
    >> [Selective snippage has damaged my intended meaning, which was that with
    >> BUF changed from 5 to 6, the 'line' array had six elements instead of
    >> five, hence 'one more element'.]
    >>
    >>> No, it doesn't.

    >>
    >> Yes, it does. See above.

    >
    > The size if line is BUF. No change of the definition of BUF is ever
    > going to change that.


    I refer the right honourable gentleman to my earlier reply. :-)

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  13. Re: Why does the output jam in the following case

    Richard Heathfield writes:
    > Rainer Weikusat said:
    >
    >> Richard Heathfield writes:
    >>> Rainer Weikusat said:
    >>>
    >>>> Richard Heathfield writes:
    >>>>> Rainer Weikusat said:
    >>>>>
    >>>
    >>>>>>
    >>>>>> #defining BUF n does not result in line[BUF] being declared to have
    >>>>>> 'one more element' than BUF.
    >>>>>
    >>>>> No, but it does result in 'line' having one more element
    >>>
    >>> [Selective snippage has damaged my intended meaning, which was that with
    >>> BUF changed from 5 to 6, the 'line' array had six elements instead of
    >>> five, hence 'one more element'.]
    >>>
    >>>> No, it doesn't.
    >>>
    >>> Yes, it does. See above.

    >>
    >> The size if line is BUF. No change of the definition of BUF is ever
    >> going to change that.

    >
    > I refer the right honourable gentleman to my earlier reply. :-)


    Your earlier replies were roughly "But when I ignore the suggestion
    and change something else instead, it won't work!". That you have
    chosen to change a macro in the code instead your left and your right
    sock is pure conicidence.

  14. Re: Why does the output jam in the following case

    Rainer Weikusat said:

    > Richard Heathfield writes:
    >> Rainer Weikusat said:
    >>


    >>>
    >>> The size if line is BUF. No change of the definition of BUF is ever
    >>> going to change that.

    >>
    >> I refer the right honourable gentleman to my earlier reply. :-)

    >
    > Your earlier replies were roughly "But when I ignore the suggestion
    > and change something else instead, it won't work!".


    My earlier replies were in the context of Jens's suggestion to "Just make
    'line' have one more element and check what happens."

    I accept that your reading of that suggestion is a legitimate
    interpretation. It seems you are unable to accept that it is not the
    *only* legitimate interpretation. There therefore seems little point in
    continuing this subthread.



    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  15. Re: Why does the output jam in the following case

    Richard Heathfield writes:
    > Rainer Weikusat said:
    >> Richard Heathfield writes:
    >>> Rainer Weikusat said:
    >>>

    >
    >>>>
    >>>> The size if line is BUF. No change of the definition of BUF is ever
    >>>> going to change that.
    >>>
    >>> I refer the right honourable gentleman to my earlier reply. :-)

    >>
    >> Your earlier replies were roughly "But when I ignore the suggestion
    >> and change something else instead, it won't work!".

    >
    > My earlier replies were in the context of Jens's suggestion to "Just make
    > 'line' have one more element and check what happens."
    >
    > I accept that your reading of that suggestion is a legitimate
    > interpretation. It seems you are unable to accept that it is not the
    > *only* legitimate interpretation.


    Interpreting the string 'line' to actually mean 'BUF' for the sole
    reason that doing wouldn't make sense is not a legitimate
    interpretation.

  16. Re: Why does the output jam in the following case

    Rainer Weikusat said:

    > Richard Heathfield writes:
    >> Rainer Weikusat said:
    >>> Richard Heathfield writes:
    >>>> Rainer Weikusat said:
    >>>>

    >>
    >>>>>
    >>>>> The size if line is BUF. No change of the definition of BUF is ever
    >>>>> going to change that.
    >>>>
    >>>> I refer the right honourable gentleman to my earlier reply. :-)
    >>>
    >>> Your earlier replies were roughly "But when I ignore the suggestion
    >>> and change something else instead, it won't work!".

    >>
    >> My earlier replies were in the context of Jens's suggestion to "Just
    >> make 'line' have one more element and check what happens."
    >>
    >> I accept that your reading of that suggestion is a legitimate
    >> interpretation. It seems you are unable to accept that it is not the
    >> *only* legitimate interpretation.

    >
    > Interpreting the string 'line' to actually mean 'BUF' for the sole
    > reason that doing wouldn't make sense is not a legitimate
    > interpretation.


    But I did not interpret 'line' to mean 'BUF'. I interpreted 'line' to mean
    the name of the array in the OP's code.

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  17. Re: Why does the output jam in the following case

    Richard Heathfield writes:
    > Rainer Weikusat said:
    >> Richard Heathfield writes:
    >>> Rainer Weikusat said:
    >>>> Richard Heathfield writes:
    >>>>> Rainer Weikusat said:
    >>>>>
    >>>
    >>>>>>
    >>>>>> The size if line is BUF. No change of the definition of BUF is ever
    >>>>>> going to change that.
    >>>>>
    >>>>> I refer the right honourable gentleman to my earlier reply. :-)
    >>>>
    >>>> Your earlier replies were roughly "But when I ignore the suggestion
    >>>> and change something else instead, it won't work!".
    >>>
    >>> My earlier replies were in the context of Jens's suggestion to "Just
    >>> make 'line' have one more element and check what happens."
    >>>
    >>> I accept that your reading of that suggestion is a legitimate
    >>> interpretation. It seems you are unable to accept that it is not the
    >>> *only* legitimate interpretation.

    >>
    >> Interpreting the string 'line' to actually mean 'BUF' for the sole
    >> reason that doing wouldn't make sense is not a legitimate
    >> interpretation.

    >
    > But I did not interpret 'line' to mean 'BUF'.


    Then please re-read the following two sentences:

    The size if line is BUF. No change of the definition of BUF is ever
    going to change that.

    In absence of understanding, you can just take this as gospel for now.


  18. Re: Why does the output jam in the following case

    Rainer Weikusat said:

    > Richard Heathfield writes:
    >> Rainer Weikusat said:
    >>> Richard Heathfield writes:




    >>>> My earlier replies were in the context of Jens's suggestion to "Just
    >>>> make 'line' have one more element and check what happens."
    >>>>
    >>>> I accept that your reading of that suggestion is a legitimate
    >>>> interpretation. It seems you are unable to accept that it is not the
    >>>> *only* legitimate interpretation.
    >>>
    >>> Interpreting the string 'line' to actually mean 'BUF' for the sole
    >>> reason that doing wouldn't make sense is not a legitimate
    >>> interpretation.

    >>
    >> But I did not interpret 'line' to mean 'BUF'.

    >
    > Then please re-read the following two sentences:
    >
    > The size if line is BUF. No change of the definition of BUF is ever
    > going to change that.


    Fine. Now please re-read the following two sentences:

    "I accept that your reading of that suggestion is a legitimate
    interpretation. It seems you are unable to accept that it is not the
    *only* legitimate interpretation."

    If you still fail to understand, you can just take this as gospel for now.

    --
    Richard Heathfield
    Email: -http://www. +rjh@
    Google users:
    "Usenet is a strange place" - dmr 29 July 1999

  19. Re: Why does the output jam in the following case

    In article <87vdyegggf.fsf@fever.mssgmbh.com>,
    Rainer Weikusat wrote:

    > Richard Heathfield writes:
    > > Rainer Weikusat said:
    > >> Richard Heathfield writes:
    > >>> Rainer Weikusat said:
    > >>>> Richard Heathfield writes:
    > >>>>> Rainer Weikusat said:
    > >>>>>
    > >>>
    > >>>>>>
    > >>>>>> The size if line is BUF. No change of the definition of BUF is ever
    > >>>>>> going to change that.
    > >>>>>
    > >>>>> I refer the right honourable gentleman to my earlier reply. :-)
    > >>>>
    > >>>> Your earlier replies were roughly "But when I ignore the suggestion
    > >>>> and change something else instead, it won't work!".
    > >>>
    > >>> My earlier replies were in the context of Jens's suggestion to "Just
    > >>> make 'line' have one more element and check what happens."
    > >>>
    > >>> I accept that your reading of that suggestion is a legitimate
    > >>> interpretation. It seems you are unable to accept that it is not the
    > >>> *only* legitimate interpretation.
    > >>
    > >> Interpreting the string 'line' to actually mean 'BUF' for the sole
    > >> reason that doing wouldn't make sense is not a legitimate
    > >> interpretation.

    > >
    > > But I did not interpret 'line' to mean 'BUF'.

    >
    > Then please re-read the following two sentences:
    >
    > The size if line is BUF. No change of the definition of BUF is ever
    > going to change that.
    >
    > In absence of understanding, you can just take this as gospel for now.


    Q: How many legs does a person have, if you call an arm a leg?

    A: Two. Calling an arm a leg doesn't make it one.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread