Scott Lurndal wrote:
>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
The open system call is defined to return '-1' on failure, not any
negative number. So the above check is incorrect. This can
cause problems with mmap, lseek and other system calls whose return
values, if declared or cast as signed, while legal are negative.
mmap() should always be checked against MAP_FAILED, and lseek return
should always be compared with the expected value (i.e. the offset
arg for SEEK_SET, and the expected offset for the other SEEK_* variants).
Would it also cause a problem if your file descriptors go "around the horn", and
exceed some platform-specific limit, such as 0x80000000? They would "go
negative" when expressed as signed integers...
It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
--
Phlip 40  2417 
[Followups to c.u.p since this subthread is getting Unix-specific]
On Aug 6, 8:08 pm, Phlip <phlip2...@gmail.comwrote:
Scott Lurndal wrote:
if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
The open system call is defined to return '-1' on failure, not any
negative number. So the above check is incorrect. This can
cause problems with mmap, lseek and other system calls whose return
values, if declared or cast as signed, while legal are negative.
mmap() should always be checked against MAP_FAILED, and lseek return
should always be compared with the expected value (i.e. the offset
arg for SEEK_SET, and the expected offset for the other SEEK_* variants).
Would it also cause a problem if your file descriptors go "around the horn", and
exceed some platform-specific limit, such as 0x80000000? They would "go
negative" when expressed as signed integers...
That's guaranteed not to happen. A file descriptor is always a non-
negative integer. So a 32-bit machine wouldn't be allowed to have
more than 2^31 open file descriptors.
So for 'open' in particular, testing for < 0 is the same as testing
for -1, since it promises never to return any other negative value.
As Scott correctly points out, though, there are other functions for
which this is not the case, and so it can be argued it's better to
form the habit of checking for the "error" value (usually -1, but not
always) specifically.
On the other hand, though, testing for < 0 is rather idiomatic. And
another common convention (though not for Unix system calls) is for a
function to be able to return any of several negative values on error,
in which case you must test for < 0. It is common for kernels to use
this convention, because they are inherently multi-threaded and can't
conveniently use something like errno. The case where the return
value is an address can complicate this approach. I believe the Linux
kernel dealt with this issue by guaranteeing that the highest page of
the address space would never be mapped, so that the values -1 through
-4096 could be used for error codes without fear of conflicting with
addresses.
It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
I don't believe so.
Phlip wrote:
Scott Lurndal wrote:
>>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
.... snip ...
>
>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
Please don't delete attributions for quoted material.
No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
On Aug 7, 7:10 am, CBFalconer <cbfalco...@yahoo.comwrote:
Phlip wrote:
Scott Lurndal wrote:
>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
... snip ...
It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
Please don't delete attributions for quoted material.
No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation. vi******@gmail.com wrote:
On Aug 7, 7:10 am, CBFalconer <cbfalco...@yahoo.comwrote:
>Phlip wrote:
Scott Lurndal wrote:
>>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
... snip ...
>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
Please don't delete attributions for quoted material.
No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
But the code need not have defined _PATH_UTMP. It could be just using
it. vi******@gmail.com writes:
On Aug 7, 7:10 am, CBFalconer <cbfalco...@yahoo.comwrote:
>Phlip wrote:
Scott Lurndal wrote:
>>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
... snip ...
>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
Please don't delete attributions for quoted material.
No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
No and yes, respectively. As it happens, _PATH_UTMP is defined by the
implementation (in one of the non-C-standard headers included by the
code we're discussing).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
CBFalconer <cb********@yahoo.comwrites:
Phlip wrote:
>Scott Lurndal wrote:
>>>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
... snip ...
>>
>>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
Please don't delete attributions for quoted material.
No standard .h file describes 'open', because open is not a
standard C defined routine.
That should have been 'no standardized C-header' (the C-standard does
not require that 'a header' corresponds with 'a file') The IEEE Std
1003.1 defined header <fcntl.his supposed to contain a prototype for
open.
CBFalconer wrote:
Please don't delete attributions for quoted material.
If they are not important to understand one post, alone, they are still
accessible in modern newsreaders' threading systems. Nobody is stealing anyone's
verbiage. vi******@gmail.com wrote:
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
Yet open() _is_ the implementation. It's just not (apparently) in the narrowest
C Standard.
On Aug 7, 3:00 pm, Phlip <phlip2...@gmail.comwrote:
CBFalconer wrote:
Please don't delete attributions for quoted material.
If they are not important to understand one post, alone, they are still
accessible in modern newsreaders' threading systems. Nobody is stealing anyone's
verbiage.
Just don't remove them. Not removing something takes less time than
removing something.
On Aug 7, 3:01 pm, Phlip <phlip2...@gmail.comwrote:
vipps...@gmail.com wrote:
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
Yet open() _is_ the implementation. It's just not (apparently) in the narrowest
C Standard.
open is the implementation? What are you trying to say?
open is POSIX, it was in older UNIX systems and it's mentioned in K&R,
but it's NOT mentioned or defined in the C standard.
Phlip wrote:
vi******@gmail.com wrote:
>Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
Yet open() _is_ the implementation. It's just not (apparently) in
the narrowest C Standard.
No, open() is not in ANY C implementation.
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/ (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2(C99, txt)
<http://www.dinkumware.com/c99.aspx (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Phlip wrote:
CBFalconer wrote:
>Please don't delete attributions for quoted material.
If they are not important to understand one post, alone, they
are still accessible in modern newsreaders' threading systems.
Nobody is stealing anyone's verbiage.
Among other things, they identify the writer. This enables the
reader to evaluate the accuracy. It is also easier to leave them
than to remove them.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section. vi******@gmail.com writes:
On Aug 7, 3:00 pm, Phlip <phlip2...@gmail.comwrote:
>CBFalconer wrote:
Please don't delete attributions for quoted material.
If they are not important to understand one post, alone, they are still
accessible in modern newsreaders' threading systems. Nobody is stealing anyone's
verbiage.
Just don't remove them. Not removing something takes less time than
removing something.
And wading through unnecessary lengthy repetition to find the new
comments can take more time. Use some common sense. If you dont have a
threaded news reader then get one.
Phlip <ph*******@gmail.comwrites:
CBFalconer wrote:
>Please don't delete attributions for quoted material.
If they are not important to understand one post, alone, they are
still accessible in modern newsreaders' threading systems. Nobody is
stealing anyone's verbiage.
Please leave the attribution lines alone anyway. I use a threaded
newsreader, but it's much easier to see the attribution line in the
article itself than to traverse up to the parent article (*if* it's
still on the server) and then figure out how to get back to the
article I was reading (non-trivial, since there can be multiple
responses).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
CBFalconer <cb********@yahoo.comwrites:
Phlip wrote:
>vi******@gmail.com wrote:
>>Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
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".
Your apparent belief that anything not defined by the ISO C standard
is not C is clearly contradicted by the ISO C standard itself.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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 article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>CBFalconer <cb********@yahoo.comwrites:
>Phlip wrote:
>>vi******@gmail.com wrote:
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
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.
In the minds of the purists, no, open() is not C and code that uses it
is not C. They often refer to these as "C-like languages".
In a group that is so tightly controlled by dogma, I think it is
imporant for you guys to get together and agree on such things, so as to
be able to present a united front to us peons.
On 7 Aug 2008 at 3:08, Phlip wrote:
Scott Lurndal wrote:
>>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).
Does some relatively standard .h file define a good constant there?
No.
Many, many standard functions - everything from readdir() to socket() to
fcntl() - follow the convention that on error they return -1 and set
errno appropriately. This isn't going to change any time soon. Checking
against -1 is therefore completely idiomatic, and a special constant
would be quite unnecessary.
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
>Phlip wrote:
>>vi******@gmail.com wrote:
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
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.
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Phlip wrote:
vi******@gmail.com wrote:
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
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.
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.
You said that "open() is not in ANY C implementation". That is simply
not true, as I explained. It's a common extension. It's not topical,
but that doesn't make it nonexistent or non-C.
<OT>
And there *are* sometimes valid reasons to use open(), which (assuming
we're talking about the POSIX open() function) has some features that
fopen() does not. With your qualification that there's *usually* no
reason to use open, you're probably right, but of course that's
off-topic.
</OT>
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
>Yet open() _is_ the implementation. It's just not (apparently) in the narrowest
>C Standard.
open is the implementation? What are you trying to say?
open is POSIX, it was in older UNIX systems and it's mentioned in K&R,
but it's NOT mentioned or defined in the C standard.
The "implementation" is everything that comes with the compiler. Put another
way, your headers are free to work in the _[A-Z] namespace, while you are free
to work in the [A-Za-z] namespace (roughly speaking), with reduced odds of a
name collision.
"The implementation" does _not_ mean "The ISO C Standard".
(BTW I deleted your screen name, just for you;)
CBFalconer wrote:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Phlip wrote:
vi******@gmail.com wrote:
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
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.
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.
And guaranteed to buffer your input, require flushes, and - if I recall
correctly, conflict between read(), seek(), and write() calls...
--
Phlip
On Aug 8, 3:22 am, Phlip <phlip2...@gmail.comwrote:
Yet open() _is_ the implementation. It's just not (apparently) in the narrowest
C Standard.
open is the implementation? What are you trying to say?
open is POSIX, it was in older UNIX systems and it's mentioned in K&R,
but it's NOT mentioned or defined in the C standard.
The "implementation" is everything that comes with the compiler. Put another
way, your headers are free to work in the _[A-Z] namespace, while you are free
to work in the [A-Za-z] namespace (roughly speaking), with reduced odds of a
name collision.
"The implementation" does _not_ mean "The ISO C Standard".
(BTW I deleted your screen name, just for you;)
Troll or too stupid, either way, from now on you are ignored.
CBFalconer wrote:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Phlip wrote:
vi******@gmail.com wrote:
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.
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.
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.
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.
I don't think I've ever use fopen in a Unix application.
--
Ian Collins.
In article <6g************@mid.individual.net>,
>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.
Not at all. You can't fopen() a pipe or socket (actually you can on
some systems), but you can fdopen() or popen() them. And of course
it's quite common for stdin/out to be pipes or sockets.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Tobin wrote:
In article <6g************@mid.individual.net>,
>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.
Not at all. You can't fopen() a pipe or socket (actually you can on
some systems), but you can fdopen() or popen() them. And of course
it's quite common for stdin/out to be pipes or sockets.
Maybe, but you can't select or poll on them or pass them to another process.
--
Ian Collins.
Ian Collins wrote:
CBFalconer wrote:
.... snip ...
>
>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.
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.
I don't think I've ever use fopen in a Unix application.
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?
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer <cb********@yahoo.comwrites:
>Ian Collins wrote:
>CBFalconer wrote:
... snip ...
>>
>>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.
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.
I don't think I've ever use fopen in a Unix application.
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'.
However, for each class of application usage one of open or fopen/fdopen
should be used based upon the needs of the application.
For reading a text file or e.g. http socket, where line-oriented semantics
are desired, fopen/fdopen and fgets are appropriate.
For high-performance I/O or for file multiplexing, one should use
open in combination with pread/pwrite, mmap or aio_read/aio_write/lio_listio
with poll/select operations as required.
For I/O to special devices (such as magnetic tapes) where the blocking
is based on the size of the I/O operation, open and read/write are
appropriate.
Buffering in stdio often hurts performance, and for certain types
of tape drives, causes undesired reblocking of the data.
scott
CBFalconer wrote:
Ian Collins wrote:
>CBFalconer wrote:
.... snip ...
>>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.
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.
I don't think I've ever use fopen in a Unix application.
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?
As others have said, that can. But the extra layer of buffering is
often undesirable but a file descriptor is more flexible.
--
Ian Collins.
Scott Lurndal wrote:
CBFalconer <cb********@yahoo.comwrites:
>Ian Collins wrote:
>>CBFalconer wrote:
... snip ...
>>>
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.
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.
I don't think I've ever use fopen in a Unix application.
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.
If interested see ppmanual.zip, available in my download section.
Unfortunately I lost most of the sources about 10 years ago in a
combination of disk failures and other disasters to backups.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer wrote:
Scott Lurndal wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>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.
Isn't that (mapping devices into C streams) what one would do with fdopen?
Different devices are opened in different ways, sockets with socket(),
pipes with pipe() and so forth.
--
Ian Collins.
Ian Collins wrote:
CBFalconer wrote:
>Scott Lurndal wrote:
>>CBFalconer <cb********@yahoo.comwrites:
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.
Isn't that (mapping devices into C streams) what one would do with
fdopen?
So I concluded. See quote above.
>
Different devices are opened in different ways, sockets with socket(),
pipes with pipe() and so forth.
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer wrote:
Ian Collins wrote:
>Different devices are opened in different ways, sockets with socket(),
pipes with pipe() and so forth.
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.
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?
--
Ian Collins.
CBFalconer wrote:
Ian Collins wrote:
>CBFalconer wrote:
>>Scott Lurndal wrote:
CBFalconer <cb********@yahoo.comwrites:
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.
Isn't that (mapping devices into C streams) what one would do with
fdopen?
So I concluded. See quote above.
>>
Different devices are opened in different ways, sockets with
socket(), pipes with pipe() and so forth.
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.
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:
CBFalconer wrote:
>Ian Collins wrote:
>>Different devices are opened in different ways, sockets with
socket(), pipes with pipe() and so forth.
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.
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?
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.
On Aug 8, 3:45 pm, CBFalconer <cbfalco...@yahoo.comwrote:
Ian Collins wrote:
CBFalconer wrote:
... snip ...
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.
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.
I don't think I've ever use fopen in a Unix application.
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 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.
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.
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:ja*********@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.comwrote:
CBFalconer wrote:
Ian Collins wrote:
Different devices are opened in different ways, sockets
with socket(), pipes with pipe() and so forth.
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.
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.
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.
How would one map a datagram socket to a stream?
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.
Or how would one open a pair (they come in pairs) of pipes
with fopen?
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:ja*********@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
Keith Thompson <ks***@mib.orgwrote:
CBFalconer <cb********@yahoo.comwrites:
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().
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 rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgwrote:
>CBFalconer <cb********@yahoo.comwrites:
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().
Of course, but how does that disagree with what I wrote?
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.
Right. On POSIX systems, open() is declared in <fcntl.h>.
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.
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) ks***@mib.org <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"
Keith Thompson <ks***@mib.orgwrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgwrote:
CBFalconer <cb********@yahoo.comwrites:
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().
Of course, but how does that disagree with what I wrote?
It means that open() may not exist for any strictly-C program.
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.
Right. On POSIX systems, open() is declared in <fcntl.h>.
So open() is not actually in the _C_ implementation, but in the _POSIX_
implementation.
Richard rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgwrote:
>rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.orgwrote:
CBFalconer <cb********@yahoo.comwrites:
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().
Of course, but how does that disagree with what I wrote?
It means that open() may not exist for any strictly-C program.
Of course. Again, how does that disagree with what I wrote?
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.
Right. On POSIX systems, open() is declared in <fcntl.h>.
So open() is not actually in the _C_ implementation, but in the _POSIX_
implementation.
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) ks***@mib.org <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" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Todd Moyer |
last post by:
I would like to use Python to parse a *python-like* data description
language. That is, it would have it's own keywords, but would have a
syntax like Python. For instance:
Ob1 ('A'):
Ob2...
|
by: silviu |
last post by:
I have the following XML string that I want to parse using the SAX
parser. If I remove the portion of the XML string between the <audit>
and </audit> tags the SAX is parsing correctly. Otherwise...
|
by: Terry |
last post by:
Hi,
This is a newbie's question. I want to preload 4 images and only when
all 4 images has been loaded into browser's cache, I want to start a
slideshow() function. If images are not completed...
|
by: Ulrich Vollenbruch |
last post by:
Hi all!
since I'am used to work with matlab for a long time and now have to work
with c/c++, I have again some problems with the usage of strings, pointers
and arrays. So please excuse my basic...
|
by: 31337one |
last post by:
Hello everyone,
I am writing an application that uses a command line interface. It will
be configurable by passing arguments on the command line. The program
is going to run in windows and...
|
by: bmichel |
last post by:
Hey,
What I'm doing is the following:
- Load XML data a file
- Parsing the XML data
- Printing some parsed content
The problem is that the script execution is stopping before all the...
|
by: jackwootton |
last post by:
Hello everyone,
I understand that XML can be parsed using JavaScript using the XML
Document object. However, it is possible to parse XHTML using
JavaScript? I currently listen for DOMMutation...
|
by: Ole Nielsby |
last post by:
(sorry, wrong button, here is the real post:)
I'm working on a C++ parser which is to be used for various
code analysis and transformation tools.
(It's part of my PILS programming system which...
|
by: Chris Carlen |
last post by:
Hi:
Having completed enough serial driver code for a TMS320F2812
microcontroller to talk to a terminal, I am now trying different
approaches to command interpretation.
I have a very simple...
|
by: CBFalconer |
last post by:
fjblurt@yahoo.com wrote:
Considering the crosspost, I won't complain about using the
non-standard open in place of fopen. However it is inappropriate
on comp.programming.
I have renamed the...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
