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 12 of 12

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? I'm I clobbering the memory?

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

    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? I'm I clobbering the memory?


    Why don't you use standardized routines, such as fopen, fread or
    fgets, fclose in place of the non-standard (and thus not
    guaranteed) open, read, close. Also exit(1) is not defined, use
    the arguments 0, EXIT_SUCCESS, EXIT_FAILURE. That way everybody
    knows exactly what you are talking about. Also you won't need
    nor .

    I suspect things have to do with printing strings without ensuring
    the object is a string.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



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

    In article <489917FE.68FD5EC7@yahoo.com>,
    CBFalconer wrote:

    > 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? I'm I clobbering the memory?

    >
    > Why don't you use standardized routines, such as fopen, fread or
    > fgets, fclose in place of the non-standard (and thus not
    > guaranteed) open, read, close.


    One of the groups he (and you) posted to is comp.unix.programmer. In
    this context, those are standard and guaranteed.

    Did you think you were reading comp.lang.c?

    --
    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 ***

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

    Barry Margolin wrote:
    > CBFalconer wrote:
    >

    .... snip ...
    >>
    >> Why don't you use standardized routines, such as fopen, fread or
    >> fgets, fclose in place of the non-standard (and thus not
    >> guaranteed) open, read, close.

    >
    > One of the groups he (and you) posted to is comp.unix.programmer.
    > In this context, those are standard and guaranteed.
    >
    > Did you think you were reading comp.lang.c?


    The same question still applies. fopen etc. are always available,
    while open etc. are restricted. They may be necessary to develop
    fopen etc. but are not as convenient. In the important cases (EX:
    fread and fgets) they are usually more efficient because of
    optimized buffer usage.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



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

    CBFalconer writes:
    > 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? I'm I clobbering the memory?

    >
    > Why don't you use standardized routines, such as fopen, fread or
    > fgets, fclose in place of the non-standard (and thus not
    > guaranteed) open, read, close.


    Because this is a UNIX(*)-program and 'open, read, close' are as
    standardized as the others.

    > Also exit(1) is not defined,


    exit(1) is completely well-defined: It returns an exit status of 1 to
    the invoking process.

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

    CBFalconer wrote:

    > Barry Margolin wrote:
    >> CBFalconer wrote:
    >>

    > ... snip ...
    >>>
    >>> Why don't you use standardized routines, such as fopen, fread or
    >>> fgets, fclose in place of the non-standard (and thus not
    >>> guaranteed) open, read, close.

    >>
    >> One of the groups he (and you) posted to is comp.unix.programmer.
    >> In this context, those are standard and guaranteed.
    >>
    >> Did you think you were reading comp.lang.c?

    >
    > The same question still applies. fopen etc. are always available,
    > while open etc. are restricted. They may be necessary to develop
    > fopen etc. but are not as convenient.


    Sometimes they are needed when you need to create files with specialised
    flags and modes that fopen knows nothing about.




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

    Rainer Weikusat wrote:
    > CBFalconer writes:
    >

    .... snip ...
    >
    >> Why don't you use standardized routines, such as fopen, fread or
    >> fgets, fclose in place of the non-standard (and thus not
    >> guaranteed) open, read, close.

    >
    > Because this is a UNIX(*)-program and 'open, read, close' are as
    > standardized as the others.


    As I said elsewhere, fopen etc. are always available, while open
    etc. are restricted. They may be necessary to develop fopen etc.
    but are not as convenient. In the important cases (EX: fread and
    fgets) they are usually more efficient because of optimized buffer
    usage.
    >
    >> Also exit(1) is not defined,

    >
    > exit(1) is completely well-defined: It returns an exit status of
    > 1 to the invoking process.


    Which is not guaranteed to be understandable to the system.
    EXIT_SUCCESS and EXIT_FAILURE (macros in stdlib.h) are guaranteed.

    In general, there is no point in writing code that requires
    deviation from the C standard, unless there is a specific reason to
    so do. It just reduces portability.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.


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

    CBFalconer writes:
    > Rainer Weikusat wrote:
    >> CBFalconer writes:
    >>

    > ... snip ...
    >>
    >>> Why don't you use standardized routines, such as fopen, fread or
    >>> fgets, fclose in place of the non-standard (and thus not
    >>> guaranteed) open, read, close.

    >>
    >> Because this is a UNIX(*)-program and 'open, read, close' are as
    >> standardized as the others.

    >
    > As I said elsewhere, fopen etc. are always available, while open
    > etc. are restricted. In the important cases (EX: fread and
    > fgets) they are usually more efficient because of optimized buffer
    > usage.


    Both are standardized UNIX(*)/POSIX-interfaces providing somewhat
    different functionality. Using stdio is usually less efficient than
    doing away with one intermediate buffer would be, which happens to be
    one of the traditional criticisms targetted at this facility. There is
    no more magic in there than an additional and usually redundant data
    copy.

    >>> Also exit(1) is not defined,

    >>
    >> exit(1) is completely well-defined: It returns an exit status of
    >> 1 to the invoking process.

    >
    > Which is not guaranteed to be understandable to the system.
    > EXIT_SUCCESS and EXIT_FAILURE (macros in stdlib.h) are guaranteed.


    Returning an exit status to something is a form of IPC. IPC (or
    anything concerned with more than a single program) is beyond the
    scope of the C-standard. How the entity receiving the exit status will
    react to it depends entirely on this entity itself.


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

    Rainer Weikusat wrote:
    > CBFalconer writes:
    >> Rainer Weikusat wrote:
    >>

    .... snip ...
    >>
    >>> exit(1) is completely well-defined: It returns an exit status of
    >>> 1 to the invoking process.

    >>
    >> Which is not guaranteed to be understandable to the system.
    >> EXIT_SUCCESS and EXIT_FAILURE (macros in stdlib.h) are guaranteed.

    >
    > Returning an exit status to something is a form of IPC. IPC (or
    > anything concerned with more than a single program) is beyond the
    > scope of the C-standard. How the entity receiving the exit status
    > will react to it depends entirely on this entity itself.


    This is not overly important, but yes, the C standard does define
    the purpose and use of EXIT_SUCCESS and EXIT_FAILURE (and 0) as
    arguments for exit, or return values from main. Anything else is
    undefined. So why use other values, when the defined values are
    quite sufficient. Use of "exit(1);" simply reduces the
    portability.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



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

    CBFalconer writes:
    > Rainer Weikusat wrote:
    >> CBFalconer writes:
    >>> Rainer Weikusat wrote:
    >>>

    > ... snip ...
    >>>
    >>>> exit(1) is completely well-defined: It returns an exit status of
    >>>> 1 to the invoking process.
    >>>
    >>> Which is not guaranteed to be understandable to the system.
    >>> EXIT_SUCCESS and EXIT_FAILURE (macros in stdlib.h) are guaranteed.

    >>
    >> Returning an exit status to something is a form of IPC. IPC (or
    >> anything concerned with more than a single program) is beyond the
    >> scope of the C-standard. How the entity receiving the exit status
    >> will react to it depends entirely on this entity itself.

    >
    > This is not overly important, but yes, the C standard does define
    > the purpose and use of EXIT_SUCCESS and EXIT_FAILURE (and 0) as
    > arguments for exit, or return values from main. Anything else is
    > undefined.


    This is wrong. The actual statement is

    If the value of status is zero or EXIT_SUCCESS, an
    implementation-defined form of the status successful
    termination is returned. If the value of status is EXIT_FAILURE,
    an implementation-defined form of the status unsuccessful
    termination is returned. Otherwise the status returned is
    implementation-defined.
    [7.20.4.3|5]

    So, whatever is used as argument to exit, the effect is that 'an
    implementation defined value' is returned to 'the host
    enviromment'. What precisely constitues 'the host environment' isn't
    defined. As I wrote above: Returning in exit status to something is an
    IPC-mechanism and the data transmitted this way is interpreted
    according to some protocol the two entities communicating with each
    other need to agree upon somehow if specific actions are supposed to
    happen in result to specific messages. Returning a non-zero exit
    status to a (usual) UNIX(*) shell means returning an (otherwise
    unspecified) failure inidication insofar the control-structure
    constructs of the shell are concerned. Reportedly, returning a zero
    exit status to the VMS command interpreter is going to be interpreted
    as 'unsuccessful termination', whatever that specifically
    means. Returning any value to an arbitrary other program interested in
    it can mean anything. This includes returning one of the numerical
    values corresponding with these two macros. Which basically means
    either it is know what 'other entity' will receive the exit status and
    how it is going to interpret a particular value, so using EXIT_* is
    completely pointless (it is actually worse because the numeric values
    are a priori unknown, eg a C implementation could as well chose the
    implementation defined values -13 und 128) or this is unknown, then
    using the EXIT_*-macros is pointless because this amounts to sending
    an unpredictable value of and unknown type somehow to an unknown
    entity, which will then do (or don't do) something.

    There is no such thing as an universal IPC-protocol.



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

    In article <4899A138.9F4E7A45@yahoo.com>,
    CBFalconer wrote:

    > Rainer Weikusat wrote:
    > > CBFalconer writes:
    > >

    > ... snip ...
    > >
    > >> Why don't you use standardized routines, such as fopen, fread or
    > >> fgets, fclose in place of the non-standard (and thus not
    > >> guaranteed) open, read, close.

    > >
    > > Because this is a UNIX(*)-program and 'open, read, close' are as
    > > standardized as the others.

    >
    > As I said elsewhere, fopen etc. are always available, while open
    > etc. are restricted.


    In what way are they restricted? You mean they're only available on
    POSIX-conformant systems? What does that leave out, 1% of the operating
    systems on the planet?

    --
    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 ***

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

    In article <4899A138.9F4E7A45@yahoo.com>,
    CBFalconer wrote:

    > In general, there is no point in writing code that requires
    > deviation from the C standard, unless there is a specific reason to
    > so do. It just reduces portability.


    More so than the hard-coded filename in his program?

    --
    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