Re: programi parsing question

[Phlip]

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

[Phlip]

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

[Phlip]

CBFalconer wrote:

Keith Thompson wrote:

>CBFalconer <cb********@yah oo.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

[vippstar]

On Aug 8, 3:22 am, Phlip <phlip2...@gmai l.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.

[Ian Collins]

CBFalconer wrote:

Keith Thompson wrote:

>CBFalconer <cb********@yah oo.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.

[Richard Tobin]

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.

[Ian Collins]

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.

[CBFalconer]

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.

[Scott Lurndal]

CBFalconer <cb********@yah oo.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

[Ian Collins]

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.

[CBFalconer]

Scott Lurndal wrote:

CBFalconer <cb********@yah oo.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.