programi parsing question - Unix

This is a discussion on programi parsing question - Unix ; vippstar@gmail.com writes: > On Aug 7, 3:00 pm, 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 ...

+ Reply to Thread
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast
Results 81 to 100 of 113

Thread: programi parsing question

  1. Re: programi parsing question

    vippstar@gmail.com writes:

    > On Aug 7, 3:00 pm, 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.

    >
    >
    > 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.

  2. Re: programi parsing question

    Phlip writes:
    > 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) kst-u@mib.org
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

  3. Re: programi parsing question

    CBFalconer writes:
    > Phlip wrote:
    >> vippstar@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) kst-u@mib.org
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

  4. Re: programi parsing question

    In article ,
    Keith Thompson wrote:
    >CBFalconer writes:
    >> Phlip wrote:
    >>> vippstar@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.


  5. Re: programi parsing question

    Keith Thompson wrote:
    > CBFalconer writes:
    >> Phlip wrote:
    >>> vippstar@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]:
    Try the download section.



  6. Re: programi parsing question

    CBFalconer writes:
    > Keith Thompson wrote:
    >> CBFalconer writes:
    >>> Phlip wrote:
    >>>> vippstar@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.


    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.


    --
    Keith Thompson (The_Other_Keith) kst-u@mib.org
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

  7. Re: programi parsing question

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

  8. Re: programi parsing question

    CBFalconer wrote:
    > Keith Thompson wrote:
    >> CBFalconer writes:
    >>> Phlip wrote:
    >>>> vippstar@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

  9. Re: programi parsing question

    On Aug 8, 3:22 am, Phlip wrote:
    > >> 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.

  10. Re: programi parsing question

    CBFalconer wrote:
    > Keith Thompson wrote:
    >> CBFalconer writes:
    >>> Phlip wrote:
    >>>> vippstar@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.

  11. Re: programi parsing question

    In article <6g2bo7Fe1fe1U1@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.

  12. Re: programi parsing question

    Richard Tobin wrote:
    > In article <6g2bo7Fe1fe1U1@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.

  13. Re: programi parsing question

    Ian Collins writes:
    > CBFalconer wrote:
    >> Keith Thompson wrote:
    >>> CBFalconer writes:
    >>>> Phlip wrote:
    >>>>> vippstar@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.


    fdopen could be used to attach a stdio-stream to any descriptor. But
    stdio is not 'some magic, portable I/O facility' but a libary which
    basically provides character stream semantics on top of a
    block-based I/O facility. To be able to do so, each stream has a write
    and a read buffer associated with it. The read buffer is filled from
    'some I/O channel' whenever an application using the library wants to
    read something which is presently not contained in it and the write
    buffer is written 'to some I/O channel' whenever there is not enough
    room in it to satisfy an output request by copying the data into the
    buffer. The likely idea behind this is that an application trying to a
    lexical analysys of some text does not need to concern itself with
    buffer management, but can process input data character-by-character
    instead. This approach has the inherent problem that the two
    lintermediate buffers necessitate making a complete additional copy of
    all input data read by an application and all output data produced by
    it. Additionally, using such a buffering schemes does not preserve
    message boundaries on either input or output. For output, it is
    possible to work around this by manageing the stdio-buffer instead, ie
    ensuring that it has a suitably large size for the largest possible
    message and flushing it whenever a complete message is contained in
    the buffer, which kind-of defeats the purpose of the stream
    implementation. Lastly, stdio has had naive multi-threading support
    added to it a while ago, preserving the 'one buffer per stream and
    process' semantics with suitable interlocking.

    Instead of copying input data into a library buffer and copying it
    from there into an application buffer, the application could just read
    the data into a buffer and work directly with it. Output messages can
    either be constructed into a buffer which is then sent with a suitable
    output system call or even just passed to the kernel as vector of
    iovec-structures. When multiple threads need to do buffered output, it
    is much more sensible when each uses a buffer of its own, so that no
    additional locking is necessary. 'Additional', because insofar the
    threads use a common 'output channel', this locking must already be
    provided by the kernel. Eg, PF_UNIX datagram sockets are defined to
    preserve message boundaries, meaning, except insofar the relative
    order of the messages itself matters, multiple threads can just send
    datagrams using the same socket descriptor freely, and the kernel
    needs to sort out anything regarding concurrent accesses on its own.
    The same is true for multi-threaded input: Instead of using a shared
    input buffer and locking to ensure that each 'datum' is returned to
    exactly one thread, multiple threads can just read the data into
    thread-private buffers, again relying on the kernel to properly
    serialize their accesses.

    'fopen' is shall be available for 'hosted' C-implementations.
    The POSIX I/O-routines shall be available on all POSIX-compliant
    systems. Inhowfar using another OS-API specific interface would
    significantly compromise the portability of an actual application
    would be a different question. For instance, anything which makes use
    of sockets, pipes, FIFOs, timers, I/O-multiplexing, multithreading,
    multiprocessing etc will not become 'more portable' by additionally
    using stdio.

  14. File mapping (was: programi parsing question)

    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]:
    Try the download section.


  15. Re: File mapping (was: programi parsing question)

    CBFalconer writes:
    >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

  16. Re: File mapping

    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.

  17. Re: File mapping (was: programi parsing question)

    Scott Lurndal wrote:
    > CBFalconer writes:
    >> 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]:
    Try the download section.


  18. Re: File mapping

    CBFalconer wrote:
    > Scott Lurndal wrote:
    >> CBFalconer 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.
    >

    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.

  19. Re: File mapping

    Ian Collins wrote:
    > CBFalconer wrote:
    >> Scott Lurndal wrote:
    >>> CBFalconer 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.

    >
    > 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]:
    Try the download section.


  20. Re: File mapping

    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.

+ Reply to Thread
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast