Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: C as a scripting language

Reply
Thread Tools

Re: C as a scripting language

 
 
Richard Bos
Guest
Posts: n/a
 
      03-29-2009
Han from China <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      03-29-2009
In article <(E-Mail Removed) t>,
Han from China <(E-Mail Removed)> 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...)

 
Reply With Quote
 
 
 
 
Harald van Dijk
Guest
Posts: n/a
 
      03-29-2009
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.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      03-30-2009
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.
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      03-30-2009
In article <(E-Mail Removed) t>,
Han from China <(E-Mail Removed)> 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.

 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      03-30-2009
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.
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      04-02-2009
Han from China <(E-Mail Removed)> 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
 
Reply With Quote
 
jameskuyper
Guest
Posts: n/a
 
      04-02-2009
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.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      04-03-2009
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Newbie survey: just a scripting language? Brian ASP .Net 2 02-06-2006 11:08 PM
Using a Scripting Language as Your Scripting Language DaveInSidney Python 0 05-09-2005 03:13 AM
any HTML/XML handling scripting language ? Bru, Pierre Java 1 10-23-2004 03:18 PM
Python is the best and most popular general purpose scripting language; the universal scripting language Ron Stephens Python 23 04-12-2004 05:32 PM
Poll: What is Your Scripting Language For Java of the Year 2003? Gerald Bauer Java 0 12-08-2003 05:21 AM



Advertisments