Re: C as a scripting language

Discussion in 'C Programming' started by Richard Bos, Mar 29, 2009.

  1. Richard Bos

    Richard Bos Guest

    Han from China <> wrote:

    > My implementation considers a return status from main() to be
    > output.


    Your implementation does not get to consider that, since the section on
    <stdio.h> defines what output is, in the context of the C Standard.
    Since the return value from main() does not go to a stream (at least not
    within C), it is not output.

    Richard
     
    Richard Bos, Mar 29, 2009
    #1
    1. Advertising

  2. In article <>,
    Han from China <> wrote:
    >Richard Bos wrote:
    >> Your implementation does not get to consider that, since the section on
    >> <stdio.h> defines what output is, in the context of the C Standard.
    >> Since the return value from main() does not go to a stream (at least not
    >> within C), it is not output.

    >
    >If that's the case, then it should be easy for you to quote that
    >section of the C Standard and show why a conforming C implementation
    >isn't allowed to consider the return status from main() as a form of
    >output. I'm not interested in your personal interpretations; I'm
    >interested in what the C Standard actually says.


    Infinite reducibility...

    (Strikes again...)
     
    Kenny McCormack, Mar 29, 2009
    #2
    1. Advertising

  3. On Sun, 29 Mar 2009 13:45:30 -0600, Han from China wrote:
    > Richard Bos wrote:
    >> Your implementation does not get to consider that, since the section on
    >> <stdio.h> defines what output is, in the context of the C Standard.
    >> Since the return value from main() does not go to a stream (at least
    >> not within C), it is not output.

    >
    > If that's the case, then it should be easy for you to quote that section
    > of the C Standard and show why a conforming C implementation isn't
    > allowed to consider the return status from main() as a form of output.


    Do you want someone to go over each and every sentence in the standard and
    explain for each one how it doesn't support your idea of a return status
    as output? The only relevant thing I can find is 7.19.2p1, and I'm having
    trouble seeing how you could link return statuses to streams.
     
    Harald van Dijk, Mar 30, 2009
    #3
  4. Richard Bos

    James Kuyper Guest

    Harald van Dijk wrote:
    > On Sun, 29 Mar 2009 13:45:30 -0600, Han from China wrote:
    >> Richard Bos wrote:
    >>> Your implementation does not get to consider that, since the section on
    >>> <stdio.h> defines what output is, in the context of the C Standard.
    >>> Since the return value from main() does not go to a stream (at least
    >>> not within C), it is not output.

    >> If that's the case, then it should be easy for you to quote that section
    >> of the C Standard and show why a conforming C implementation isn't
    >> allowed to consider the return status from main() as a form of output.


    More precisely, it is the "termination status returned to the host
    environment", by either a call to exit() or by returning from the
    initial call to main(), which is a form of output. The return status
    from a non-initial call to main() is certainly not a output.

    > Do you want someone to go over each and every sentence in the standard and
    > explain for each one how it doesn't support your idea of a return status
    > as output? The only relevant thing I can find is 7.19.2p1, and I'm having
    > trouble seeing how you could link return statuses to streams.


    This question is being raised in the context of section 4p5, which does
    not restrict the 'output' to be stream output. The standard does not
    define 'output', leaving it to be interpreted in accordance with
    conventional English usage in the context of computer programming. The
    standard uses the word 'output' in at least one context where it clearly
    does not refer to stream output: footnote 116 refers to a "memory-mapped
    input/output port" (I didn't bother searching further after finding the
    first such example).

    I cannot come up with any reasonable definition of the term 'output',
    consistent with the normal usage of English in the computer world, that
    includes both stream and port I/O, while failing to include the exit
    status of the program. This is all information generated by the program,
    and communicated outward from the program.

    I've looked and found several definitions of 'output' that clearly
    exclude the exit status. However, those same definitions also exclude
    data written to a file, for precisely the same reason: for some of those
    definitions, the reason is that the data is not perceived by the user;
    for other definitions, it is because the data has not exited the
    computer system. In either case, the reason applies just as easily to
    the exit status as to data written to a file. I consider this a defect
    in those definitions. Taken literally, use of those definitions in the
    interpretation of section 4p5 implies that data written to a file has no
    effect upon whether or not a program is strictly conforming.
     
    James Kuyper, Mar 30, 2009
    #4
  5. In article <>,
    Han from China <> wrote:
    >Kenny McCormack wrote:
    >> Infinite reducibility...
    >>
    >> (Strikes again...)

    >
    >Indeed. I'm still trying to figure out why a conforming C implementation
    >can't declare popen() in stdio.h, as Keith implies. Certainly that
    >view isn't supported by the standard.
    >
    >What's happening is a case of "selective pedantry": if an exact
    >reading of the standard conflicts with topicality or an attack on
    >a compiler writer, be "practical" and consider "real-world"
    >implementations; otherwise, use exact readings to attack that
    >compiler writer and newcomers or to revel in such marvels as why,
    >for instance, (void *)0 is a null pointer constant but ((void *)0)
    >isn't.


    Yup. They really, really, really, really, really don't like the fact
    that they are being hoist(ed) on their own petard(s). It is really good
    to see you sticking it to them using their own tools.
     
    Kenny McCormack, Mar 30, 2009
    #5
  6. On Sun, 29 Mar 2009 19:05:17 -0600, Han from China wrote:
    > Since my implementation considers the termination status of a program to
    > be data that undergoes a transfer outside a part of the system, all the
    > above is telling me is that the termination status is mapped into a
    > logical data stream that is either a text stream or a binary stream.
    >
    > Where's that telling me that the termination status of a program isn't
    > output?


    I was thinking of

    7.19.3p5:
    "If the main function returns to its original caller, or if the exit
    function is called, all open files are closed (hence all output streams
    are flushed) *before* program termination." (emphasis mine)

    but looking closer, I don't see the standard specifying whether output
    streams that are not associated with files are closed at all, before or
    after program termination.
     
    Harald van Dijk, Mar 30, 2009
    #6
  7. Richard Bos

    Richard Bos Guest

    Han from China <> wrote:

    > Richard Bos wrote:
    > > Your implementation does not get to consider that, since the section on
    > > <stdio.h> defines what output is, in the context of the C Standard.
    > > Since the return value from main() does not go to a stream (at least not
    > > within C), it is not output.

    >
    > If that's the case, then it should be easy for you to quote that
    > section of the C Standard and show why a conforming C implementation
    > isn't allowed to consider the return status from main() as a form of
    > output. I'm not interested in your personal interpretations; I'm
    > interested in what the C Standard actually says.


    7.19.2#1:

    # Input and output, whether to or from physical devices such as
    # terminals and tape drives, or whether to or from files supported on
    # structured storage devices, are mapped into logical data streams...

    Since nowhere else in the Standard says how any other kind of output is
    done, the conclusion must be that all output of an ISO C program goes
    through streams, and that therefore the return value from main() does
    not count as output.

    Richard
     
    Richard Bos, Apr 2, 2009
    #7
  8. Richard Bos

    jameskuyper Guest

    Richard Bos wrote:
    ....
    > 7.19.2#1:
    >
    > # Input and output, whether to or from physical devices such as
    > # terminals and tape drives, or whether to or from files supported on
    > # structured storage devices, are mapped into logical data streams...
    >
    > Since nowhere else in the Standard says how any other kind of output is
    > done, the conclusion must be that all output of an ISO C program goes
    > through streams, and that therefore the return value from main() does
    > not count as output.


    Note that the word "streams" is in italic in that sentence, indicating
    that it constitutes a definition of a stream. It is NOT a definition
    of either "output" or "input", or indeed any other word that appears
    in that sentence. As such, it is saying that those kinds of input and
    output are handled through streams. It should not be interpreted as
    restricting input or output to streams.

    Section 3p1 says "Terms not defined in this International Standard are
    to be interpreted according to ISO/IEC 2382-1." However, I can't
    justify paying ISO's price for 2382-1, so I'm not sure whether it has
    a definition for "output". If it doesn't have one, then ordinary
    English usage in the context of computers would determine what the
    word means. However, any definition of "output" that excludes data
    that is PUT OUTward from a program to the external environment through
    the termination status is a defective definition, as far as I can see.
    I can't figure out how the word "output", if defined that way, would
    be useful. Just about anything I would want to say about "output" in
    general (as opposed to a specific type of output) would certainly be
    intended to include the termination status. I've written more than a
    few programs where the correct usage of the program required paying
    attention to that particular form of output to determine what the rest
    of a shell script or makefile build rule should do.
     
    jameskuyper, Apr 2, 2009
    #8
  9. Richard Bos

    James Kuyper Guest

    pete wrote:
    > jameskuyper wrote:

    ....
    >> Section 3p1 says "Terms not defined in this International Standard are
    >> to be interpreted according to ISO/IEC 2382-1." However, I can't
    >> justify paying ISO's price for 2382-1, so I'm not sure whether it has
    >> a definition for "output".

    >
    > "Other terms such as vocabulary, concept, term and
    > definition, are used in this part of ISO/IEC 2382 with the
    > meaning defined in IS0 1087."
    >
    > At which point I conclude that every ISO document
    > is in fact an advertisment for another ISO document.


    I wouldn't be surprised; it's pretty much what I'd expect from a
    standards organization that's been around as long as ISO.

    > ISO/IEC
    > 2382-l
    > Third edition
    >
    > 01 .01.33 01.01.33
    > output (data)
    > Data that an information processing system, or any of its
    > parts, transfers outside of that system or part.


    If the "part" that you're talking about is a program, the termination
    status is clearly information, and it clearly gets transferred out of
    the program. So it is part of the program's output.
     
    James Kuyper, Apr 3, 2009
    #9
    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. Brian
    Replies:
    2
    Views:
    380
    Kevin Spencer
    Feb 6, 2006
  2. Gerald Bauer
    Replies:
    0
    Views:
    338
    Gerald Bauer
    Dec 8, 2003
  3. Bru, Pierre
    Replies:
    1
    Views:
    386
    Martin Honnen
    Oct 23, 2004
  4. Ron Stephens
    Replies:
    23
    Views:
    3,019
    Ron Stephens
    Apr 12, 2004
  5. DaveInSidney
    Replies:
    0
    Views:
    459
    DaveInSidney
    May 9, 2005
Loading...

Share This Page