programi parsing question - Unix

This is a discussion on programi parsing question - Unix ; CBFalconer wrote: > 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. ...

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6
Results 101 to 113 of 113

Thread: programi parsing question

  1. Re: File mapping

    CBFalconer wrote:

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


    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.


  2. Re: File mapping

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



  3. Re: File mapping

    santosh wrote:
    > CBFalconer wrote:
    >> Ian Collins wrote:
    >>

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


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



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

    On Aug 8, 3:45 pm, 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?


    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 "//hostort/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: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

  5. Re: File mapping

    On Aug 9, 6:14 am, 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.


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

  6. Re: File mapping

    On Aug 9, 9:15 am, santosh wrote:
    > CBFalconer 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.


    > Fopen would get unusably complex if it were to be the common
    > open function for all sorts of system specific devices.


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

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


    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

  7. Re: File mapping

    James Kanze writes:
    > On Aug 9, 9:15 am, santosh wrote:
    >> CBFalconer 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.

    >
    >> Fopen would get unusably complex if it were to be the common
    >> open function for all sorts of system specific devices.

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


    I would assume 'regular files' were meant.

    [...]

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

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


    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.

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


    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.

  8. Re: programi parsing question

    Keith Thompson wrote:

    > CBFalconer 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().

    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

  9. Re: programi parsing question

    rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:
    > Keith Thompson wrote:
    >> CBFalconer 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().


    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 .

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

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

  10. Re: programi parsing question

    In comp.unix.programmer Rainer Weikusat wrote:
    | phil-news-nospam@ipal.net writes:
    |> In comp.unix.programmer Rainer Weikusat 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) |

  11. Re: programi parsing question

    phil-news-nospam@ipal.net writes:
    > In comp.unix.programmer Rainer Weikusat wrote:
    > | phil-news-nospam@ipal.net writes:


    [...]

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


    [...]

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


    [...]

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


    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.


  12. Re: programi parsing question

    Keith Thompson wrote:

    > rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:
    > > Keith Thompson wrote:
    > >> CBFalconer 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().

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


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

    Richard

  13. Re: programi parsing question

    rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:
    > Keith Thompson wrote:
    >> rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:
    >> > Keith Thompson wrote:
    >> >> CBFalconer 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().

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

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

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