programi parsing question

CBFalconer wrote:
[color=blue]
> Ian Collins wrote:[color=green]
>> CBFalconer wrote:[color=darkred]
>>> Scott Lurndal wrote:
>>>> CBFalconer <cbfalconer@yahoo.com> writes:
>>>>
>>>>> Interesting. I don't think I have ever actually used a POSIX
>>>>> system as such, so this is entirely new to me. Why can't pipes
>>>>> and sockets be mapped into streams?
>>>>
>>>> They can, as pointed out above, be mapped with 'fdopen'.
>>>
>>> Well, the quick look I just took at some manuals (not standards)
>>> here indicates that fdopen is basically a way of converting a file
>>> opened by 'open' to one opened by 'fopen'. I have virtually never
>>> needed to use such POSIX extensions.
>>>
>>> As I pointed out before, I had no problem mapping devices into the
>>> Pascal file system. This involved a set of routines, that had to
>>> be built for each such file type. I forget the details, but I
>>> could look it up (I still have the assembly listings). There were
>>> some complications, because Pascal doesn't require fopen/fclose,
>>> rather it opens access automatically based on the declarations.
>>> However, there are reset/rewrite routine involvement.[/color]
>>
>> Isn't that (mapping devices into C streams) what one would do with
>> fdopen?[/color]
>
> So I concluded. See quote above.
>[color=green]
>>
>> Different devices are opened in different ways, sockets with
>> socket(), pipes with pipe() and so forth.[/color]
>
> But that means someone has to write the open function. Why? Why
> can't we just write a fopen function? This means having a method
> of expanding the existing fopen. Maybe this is just cavilling
> about names.[/color]

Fopen would get unusably complex if it were to be the common open
function for all sorts of system specific devices. Some devices are
found only on some systems, others on others, each device has different
properties, features, flags etc. How is WG14 going to come up with a
common model for this huge set of devices and semantics, to encapsulate
into a single function.

That's why they decided to model a simply byte stream with FILE and let
each system link as many devices to it, as it can meaningfully do so.
In the process portability is gained but fine-grained control is lost.

Ian Collins wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> Ian Collins wrote:
>>[color=darkred]
>>> Different devices are opened in different ways, sockets with
>>> socket(), pipes with pipe() and so forth.[/color]
>>
>> But that means someone has to write the open function. Why?
>> Why can't we just write a fopen function? This means having a
>> method of expanding the existing fopen. Maybe this is just
>> cavilling about names.[/color]
>
> Anything's possible, but fopen is defined by the C standard to
> open a file. If it were to be used for other devices, they
> would have to behave like a file. How would one map a datagram
> socket to a stream? Or how would one open a pair (they come in
> pairs) of pipes with fopen?[/color]

Well, I can't answer your question because I don't know enough
about those devices. But I can illustrate what I did 30 or so
years ago for some embedded applications.

I needed an array of 90 positions, at each of which the operator
could enter a 4 digit 'accession number'. This identified a
sample, on a short (2 day) rotation, and avoided any privacy
invasions. This was medical testing data. So I provided a record,
in Pascal, of roughly:

maxix = 99
maxacc = 9999
screen = RECORD
accno : ARRAY 10..maxix OF 0..maxacc;
locn : 10..99;
END;

and the value 0000 indicated an accno was not entered. The file
item was one such record. Now I built the driver to move between
fixed points on the screen (90 of them). The driver noticed, and
revised the locn value. This formed a new record value, and
updated the f^ (i.e. the record maintained in the system for the
device), and signalled the movement. Similarly operator alteration
of the displayed accno.

The point was that the transmissions were minimized, there was one
record with the complete screen information available, and the
operator could modify it freely. Sample processing took roughly 10
minutes, and once the sample was processed the mechanism blanked
the recorded accno.

This control mechanism was used on multiple machines that processed
various tests for a 1000 bed hospital. Also the Emergency, etc.
So it was worthwhile getting the interface clear and repeatable.

Similar things were done to handle the local network, which
reported test results to a central machine. That network was a
queer thing, since I had to keep things working that had been
designed by predecessors in the 60s and early 70s. Since I did
these things so long ago, some things are hazy, and thus so is the
description. However they worked very well, and reliably. Those
systems were in place and running trouble free for at least 10 to
12 years before I left in '87.

By the way, those mechanisms fitted perfectly into the ISO
description of Pascal files. All these systems were programmed in
ISO standard Pascal. The drivers were in assembly language.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

santosh wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> Ian Collins wrote:
>>[/color][/color]
.... snip ...[color=blue][color=green]
>>[color=darkred]
>>> Isn't that (mapping devices into C streams) what one would do with
>>> fdopen?[/color]
>>
>> So I concluded. See quote above.
>>[color=darkred]
>>> Different devices are opened in different ways, sockets with
>>> socket(), pipes with pipe() and so forth.[/color]
>>
>> But that means someone has to write the open function. Why? Why
>> can't we just write a fopen function? This means having a method
>> of expanding the existing fopen. Maybe this is just cavilling
>> about names.[/color]
>
> Fopen would get unusably complex if it were to be the common open
> function for all sorts of system specific devices. Some devices are
> found only on some systems, others on others, each device has different
> properties, features, flags etc. How is WG14 going to come up with a
> common model for this huge set of devices and semantics, to encapsulate
> into a single function.
>
> That's why they decided to model a simply byte stream with FILE and let
> each system link as many devices to it, as it can meaningfully do so.
> In the process portability is gained but fine-grained control is lost.[/color]

Yes, I guess that is the critical difference. The Pascal file
system wasn't limited to byte streams, so I could build monsters
around any RECORD design I pleased (struct to you). Then the
streams were of that record.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

On Aug 8, 3:45 pm, CBFalconer <cbfalco...@yahoo.com> wrote:[color=blue]
> Ian Collins wrote:[color=green]
> > CBFalconer wrote:[/color][/color]
[color=blue]
> ... snip ...[/color]
[color=blue][color=green][color=darkred]
> >> Why does everyone misinterpret my concern here? It must be what I
> >> wrote. At any point, my point is that there is usually NO reason
> >> to use open, when fopen is guaranteed to be documented and
> >> available.[/color][/color][/color]
[color=blue][color=green]
> > Quite the reverse in a POSIX environment. A FILE* restricts you to
> > working with files, a file descriptor can be used for other entities
> > such as pipes and sockets.[/color][/color]
[color=blue][color=green]
> > I don't think I've ever use fopen in a Unix application.[/color][/color]
[color=blue]
> Interesting. I don't think I have ever actually used a POSIX
> system as such, so this is entirely new to me. Why can't
> pipes and sockets be mapped into streams?[/color]

They could be, but they normally aren't. I'm not sure whether
it would still be Posix conformant, but there's no reason why
fopen couldn't create a pipe, rather than open a file, if the
"filename" started with an "!". (Actually, I'm pretty sure that
it wouldn't be conformant, since you're allowed to have
filenames of actual files whose name starts with a "!".) And
Posix definitely does allow things like "//host:port/path"; if a
filename starts with "//", its meaning is implementation
defined.
[color=blue]
> For comparison, 25 years ago I had no difficulty mapping
> anything into Pascal files. That was proper Pascal, with f^,
> put, and get. Once you have the proper type for the file
> items, everything follows. Remember that Pascal creates new
> user types on demand, and those types can be records.[/color]

Yes, but you still needed some special mechanism to associate
the file type with its external support. The fact that file
types could be records is more like the fact that iostream in
C++ is a template: you're not changing the association with the
external entity, but rather the unit of data which is transfered
(instead of just char).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Aug 9, 6:14 am, Ian Collins <ian-n...@hotmail.com> wrote:[color=blue]
> CBFalconer wrote:[color=green]
> > Ian Collins wrote:[/color][/color]
[color=blue][color=green][color=darkred]
> >> Different devices are opened in different ways, sockets
> >> with socket(), pipes with pipe() and so forth.[/color][/color][/color]
[color=blue][color=green]
> > But that means someone has to write the open function. Why?
> > Why can't we just write a fopen function? This means having
> > a method of expanding the existing fopen. Maybe this is
> > just cavilling about names.[/color][/color]
[color=blue]
> Anything's possible, but fopen is defined by the C standard to
> open a file. If it were to be used for other devices, they
> would have to behave like a file.[/color]

Posix defines a file as "An object that can be written to, or
read from, or both." A pipe is a file. A socket is a file.

Note too the definition of "Absolute Pathname": "A pathname
beginning with a single or more than two slashes". If a
pathname begins with exactly two slashes, Posix doesn't say what
it means, which means that the implementation is free to do
whatever it wants.
[color=blue]
> How would one map a datagram socket to a stream?[/color]

However the implementation wants:-). I can think of two
possibilities; the most reasonable (IMHO) is that nothing gets
sent unless there is an explicit fflush() or fclose(), at which
time all outstanding data gets sent as a single datagram.
[color=blue]
> Or how would one open a pair (they come in pairs) of pipes
> with fopen?[/color]

It would depend on the modes of the fopen(): basically, however,
there's nothing to prevent an implementation from implementing
fopen( "//! some system command" ... ) from creating a pipe to
and/or from a new process, and starting the command in that.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Aug 9, 9:15 am, santosh <santosh....@gmail.com> wrote:[color=blue]
> CBFalconer wrote:[/color]

[...][color=blue][color=green][color=darkred]
> >> Different devices are opened in different ways, sockets with
> >> socket(), pipes with pipe() and so forth.[/color][/color]
>[color=green]
> > But that means someone has to write the open function. Why? Why
> > can't we just write a fopen function? This means having a method
> > of expanding the existing fopen. Maybe this is just cavilling
> > about names.[/color][/color]
[color=blue]
> Fopen would get unusably complex if it were to be the common
> open function for all sorts of system specific devices.[/color]

But that's already the case. Unix "defines" all sorts of system
specific devices as "files". (Take a look at what you find in
/dev, for example. Or /proc. And they can be very special---I
recently used "/dev/stderr" in AWK, for example.)
[color=blue]
> Some devices are found only on some systems, others on others,
> each device has different properties, features, flags etc. How
> is WG14 going to come up with a common model for this huge set
> of devices and semantics, to encapsulate into a single
> function.[/color]
[color=blue]
> That's why they decided to model a simply byte stream with
> FILE and let each system link as many devices to it, as it can
> meaningfully do so. In the process portability is gained but
> fine-grained control is lost.[/color]

Yes and no. You can read and write from a socket using the file
read() and write() functions; once it's open, you can pretty
much treat a socket or a pipe as if it were a file, if that's
what you want. You do loose access to some of the options, but
that's your choice. The only thing that's missing is some sort
of syntax for the fopen, and Posix formally provides for that:
if the filename argument begins with "//[^/]", how it's
interpreted is not defined by Posix. So fopen( "//! ls", "r" )
reads from ls, over a pipe, and fopen( "//www.google.com:80",
"r+" ) opens a TCP connection to Google (but it's up to you to
implement HTTP over it).

From a QoI point of view, this is really what I'd expect. (Or
is "quality" and "Unix" an oxymoron?)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze <james.kanze@gmail.com> writes:[color=blue]
> On Aug 9, 9:15 am, santosh <santosh....@gmail.com> wrote:[color=green]
>> CBFalconer wrote:[/color]
>
> [...][color=green][color=darkred]
>> >> Different devices are opened in different ways, sockets with
>> >> socket(), pipes with pipe() and so forth.[/color]
>>[color=darkred]
>> > But that means someone has to write the open function. Why? Why
>> > can't we just write a fopen function? This means having a method
>> > of expanding the existing fopen. Maybe this is just cavilling
>> > about names.[/color][/color]
>[color=green]
>> Fopen would get unusably complex if it were to be the common
>> open function for all sorts of system specific devices.[/color]
>
> But that's already the case. Unix "defines" all sorts of system
> specific devices as "files". (Take a look at what you find in
> /dev, for example. Or /proc. And they can be very special---I
> recently used "/dev/stderr" in AWK, for example.)[/color]

I would assume 'regular files' were meant.

[...]
[color=blue][color=green]
>> That's why they decided to model a simply byte stream with
>> FILE and let each system link as many devices to it, as it can
>> meaningfully do so. In the process portability is gained but
>> fine-grained control is lost.[/color]
>
> Yes and no. You can read and write from a socket using the file
> read() and write() functions; once it's open, you can pretty
> much treat a socket or a pipe as if it were a file, if that's
> what you want. You do loose access to some of the options, but
> that's your choice. The only thing that's missing is some sort
> of syntax for the fopen, and Posix formally provides for that:
> if the filename argument begins with "//[^/]", how it's
> interpreted is not defined by Posix. So fopen( "//! ls", "r" )
> reads from ls, over a pipe, and fopen( "//www.google.com:80",
> "r+" ) opens a TCP connection to Google (but it's up to you to
> implement HTTP over it).[/color]

Network protocols cannot usually tolerate unknown delays and arbitrary
rearrangement of messages. And while fopen could certainly be extended
to create all different kinds of file descriptors, such an expansion
would already be non-portable, nullifying the desired greater
portability.
[color=blue]
> From a QoI point of view, this is really what I'd expect. (Or
> is "quality" and "Unix" an oxymoron?)[/color]

From a 'QoI point of view', application shouldn't be using stdio
mereley because it exists, but because something is gained by doing
so. I would usually expect this to be the case when a single-threaded
application is actually written to work with character streams and the
speed of the I/O-processing isn't relevant (I have used simple
linear-buffer based [output] streams in place of stdio-streams,
because this was simply faster. IMO, the per-stream buffer is a design
error in multithreaded applications and the locking necessary for
serializing accesses to this buffer from multiple threads should
rather be avoided.

Keith Thompson <kst-u@mib.org> wrote:
[color=blue]
> CBFalconer <cbfalconer@yahoo.com> writes:[color=green]
> > Phlip wrote:[color=darkred]
> >> Yet open() _is_ the implementation. It's just not (apparently) in
> >> the narrowest C Standard.[/color]
> >
> > No, open() is not in ANY C implementation.[/color]
>
> Yes, it certainly is in many C implementations. It's not defined by
> the C standard, but it's allowed as an extension.
>
> C99 4p6:
>
> A conforming implementation may have extensions (including
> additional library functions), provided they do not alter the
> behavior of any strictly conforming program.
>
> open() is one of these "additional library functions".[/color]

Not so; a strictly conforming program may itself define open().

What a C implementation _may_ do is declaring open() in a non-Standard
header, since #including such a header renders a program not strictly
conforming anyway.

Whether that means that open() is in such a C implementation, or that
that implementation consists of a C implementation _plus_ a POSIX (or
whatever) library implementation, is something about which one could
debate until the cows come home. Fact remains that a _C_ program cannot
rely on open() being what the OP expects it to be, while a _C plus
POSIX_ program can.

Richard

[email]rlb@hoekstra-uitgeverij.nl[/email] (Richard Bos) writes:[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:[color=green]
>> CBFalconer <cbfalconer@yahoo.com> writes:[color=darkred]
>> > Phlip wrote:
>> >> Yet open() _is_ the implementation. It's just not (apparently) in
>> >> the narrowest C Standard.
>> >
>> > No, open() is not in ANY C implementation.[/color]
>>
>> Yes, it certainly is in many C implementations. It's not defined by
>> the C standard, but it's allowed as an extension.
>>
>> C99 4p6:
>>
>> A conforming implementation may have extensions (including
>> additional library functions), provided they do not alter the
>> behavior of any strictly conforming program.
>>
>> open() is one of these "additional library functions".[/color]
>
> Not so; a strictly conforming program may itself define open().[/color]

Of course, but how does that disagree with what I wrote?
[color=blue]
> What a C implementation _may_ do is declaring open() in a non-Standard
> header, since #including such a header renders a program not strictly
> conforming anyway.[/color]

Right. On POSIX systems, open() is declared in <fcntl.h>.
[color=blue]
> Whether that means that open() is in such a C implementation, or that
> that implementation consists of a C implementation _plus_ a POSIX (or
> whatever) library implementation, is something about which one could
> debate until the cows come home. Fact remains that a _C_ program cannot
> rely on open() being what the OP expects it to be, while a _C plus
> POSIX_ program can.[/color]

Agreed.

A conforming implementation may have extensions. One such extension
is providing a function called "open" in a header called <fcntl.h>.

--
Keith Thompson (The_Other_Keith) [email]kst-u@mib.org[/email] <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

In comp.unix.programmer Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
| [email]phil-news-nospam@ipal.net[/email] writes:
|> In comp.unix.programmer Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
|>
|> | I don't think that people who consider 'programming language grammar
|> | and syntax' to be 'a really hard problem' will ever write a useful
|> | program. That would be close to expecting first-graders struggling
|> | with expressing themselves in writing to publish enlightening treaties
|> | on epistemology. Programming languages are tools (or toys :-). The
|> | world is a complex thing and most of the (unsolved) problems that
|> | spring from it are hard problems in their own right. Solving them
|> | requires use of suitable tools, not necessarily familiar ones.
|>
|> I don't doubt there are problems where the familiarity of the tool is
|> overshadowed by the suitability of the tool. The lack of familiarity
|> with a tool can impose the cost of becoming familiar to some degree
|> based on what the problem is (I can't think of a case where it would
|> not). I happen to be unfamiliar with Java and barely familiar with
|> Perl. I could write a hello world program far faster in C simply
|> because I am familar with it.
|
| And how often have you been writing 'Hello, world'-programs because of
| an externally imposed requirement ('job') to do so lately? Not very
| often, I guess. The point I was trying to make is that a particular
| programming language is usually a non-negotiable part of some set of
| technical requirements. Eg, I ocassionally need to do modifications to
| a web portal which has been written in procedural PHP4 and it doesn't
| matter the least if $random_fashionable_language would initially have
| been the better choice. In a similar fashion, when I have to solve
| some so-called 'low-level' programming problem for 'our' device
| platform, the code will either be ARM9 assembly or C, because the
| devices have an ARM926SEJ-CPU and run a Linux (2.4) kernel.

Not all technical requirements specify a language. When a company does a
lot of programming and have decided on a language so that programmers can
each be assigned to do other projects, then it makes sense. If it's a Java
shop, then you are expected to code Java or not work there. If a project
leans towards being do in some other language, it can still be appropriate
to do it in Java, anyway, THERE.

A programmer who knows only Java, doing a new project on her own, will
almost certainly choose Java for projects that lean towards other languages.
That might reach a breaking point early if it's something better done in C.
But such projects tend to be not in the realm of most Java programmers.

Of course a lot of things can easily be done in a lot of languages. For
example: a web server


| Given the unholy amount of existing (OSS) software written in C which
| is lying around everywhere, I doubt that someone can seriously work on
| general 'programming tasks' without having a good, working knowledge
| of C. Not writing something from scratch in Java (here chosen because
| 'rewrite the world' is apparently very popular among Java-confined
| people), but adapating existing C code to a new task is going to be
| easier and faster and will lead to a higher quality product just
| because most parts of the existing code have already been debugged (by
| someone else).

That depends on how far the new task departs from the original thoughts of
the programmer of the code being reused.


| In some moderately distant past, I needed to interact with a
| Postscript-interpreter, so I learnt (and forgot :-) Postscript.

Oh those days :-) I hand coded some Postscript to make some interesting
artwork for some newspaper ads I was making. SVG is harder by comparison.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

[email]phil-news-nospam@ipal.net[/email] writes:[color=blue]
> In comp.unix.programmer Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> | [email]phil-news-nospam@ipal.net[/email] writes:[/color]

[...]
[color=blue]
> |> I don't doubt there are problems where the familiarity of the tool is
> |> overshadowed by the suitability of the tool. The lack of familiarity
> |> with a tool can impose the cost of becoming familiar to some degree
> |> based on what the problem is[/color]

[...]
[color=blue]
> | And how often have you been writing 'Hello, world'-programs because of
> | an externally imposed requirement ('job') to do so lately? Not very
> | often, I guess. The point I was trying to make is that a particular
> | programming language is usually a non-negotiable part of some set of
> | technical requirements.[/color]

[...]
[color=blue]
> Not all technical requirements specify a language. When a company does a
> lot of programming and have decided on a language so that programmers can
> each be assigned to do other projects, then it makes sense. If it's a Java
> shop, then you are expected to code Java or not work there.[/color]

Which is precisely the situation I was writing about: It is required
that a particular language is to be used because of factors external
to the language itself. It doesn't matter if using some other language
would be advantageous because of .... and whoever is going to work on
this particular project will have to learn this language. This would
be an administrative and not a technical requirement, but it would
render any language except Java as unsuitable as a technical
requirement would.

Keith Thompson <kst-u@mib.org> wrote:
[color=blue]
> [email]rlb@hoekstra-uitgeverij.nl[/email] (Richard Bos) writes:[color=green]
> > Keith Thompson <kst-u@mib.org> wrote:[color=darkred]
> >> CBFalconer <cbfalconer@yahoo.com> writes:
> >> > Phlip wrote:
> >> >> Yet open() _is_ the implementation. It's just not (apparently) in
> >> >> the narrowest C Standard.
> >> >
> >> > No, open() is not in ANY C implementation.
> >>
> >> Yes, it certainly is in many C implementations. It's not defined by
> >> the C standard, but it's allowed as an extension.
> >>
> >> C99 4p6:
> >>
> >> A conforming implementation may have extensions (including
> >> additional library functions), provided they do not alter the
> >> behavior of any strictly conforming program.
> >>
> >> open() is one of these "additional library functions".[/color]
> >
> > Not so; a strictly conforming program may itself define open().[/color]
>
> Of course, but how does that disagree with what I wrote?[/color]

It means that open() may not exist for any strictly-C program.
[color=blue][color=green]
> > What a C implementation _may_ do is declaring open() in a non-Standard
> > header, since #including such a header renders a program not strictly
> > conforming anyway.[/color]
>
> Right. On POSIX systems, open() is declared in <fcntl.h>.[/color]

So open() is not actually in the _C_ implementation, but in the _POSIX_
implementation.

Richard

[email]rlb@hoekstra-uitgeverij.nl[/email] (Richard Bos) writes:[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:[color=green]
>> [email]rlb@hoekstra-uitgeverij.nl[/email] (Richard Bos) writes:[color=darkred]
>> > Keith Thompson <kst-u@mib.org> wrote:
>> >> CBFalconer <cbfalconer@yahoo.com> writes:
>> >> > Phlip wrote:
>> >> >> Yet open() _is_ the implementation. It's just not (apparently) in
>> >> >> the narrowest C Standard.
>> >> >
>> >> > No, open() is not in ANY C implementation.
>> >>
>> >> Yes, it certainly is in many C implementations. It's not defined by
>> >> the C standard, but it's allowed as an extension.
>> >>
>> >> C99 4p6:
>> >>
>> >> A conforming implementation may have extensions (including
>> >> additional library functions), provided they do not alter the
>> >> behavior of any strictly conforming program.
>> >>
>> >> open() is one of these "additional library functions".
>> >
>> > Not so; a strictly conforming program may itself define open().[/color]
>>
>> Of course, but how does that disagree with what I wrote?[/color]
>
> It means that open() may not exist for any strictly-C program.[/color]

Of course. Again, how does that disagree with what I wrote?
[color=blue][color=green][color=darkred]
>> > What a C implementation _may_ do is declaring open() in a non-Standard
>> > header, since #including such a header renders a program not strictly
>> > conforming anyway.[/color]
>>
>> Right. On POSIX systems, open() is declared in <fcntl.h>.[/color]
>
> So open() is not actually in the _C_ implementation, but in the _POSIX_
> implementation.[/color]

Which is (or at least may be) part of the C implementation. It's an
*extension*. It's an additional library function that doesn't alter
the behavior of any strictly conforming program. It is therefore
something that a conforming C implementation is allowed to have.

--
Keith Thompson (The_Other_Keith) [email]kst-u@mib.org[/email] <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"