Re: non-standard functions in libc -- bad design?

On 1 Oct, 07:06, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
In article <Id-dnR7yvrB_o17XnZ2dnUVZ_hqdn...@xxxxxxxxxxxxxxxxxxxxxx>,
Gordon Burditt <gordonb.9c...@xxxxxxxxxxx> wrote:

I've been involved, in another context, in a long and contentious
discussion about whether functions that are part of the POSIX
standard but not the C standard -- getpid() in particular --
should be regarded as "third-party".  

I don't think "third-part" is a very useful/helpful term.


If it comes with the OS, and it's used by the C implementation, I
don't think "third-party" is the right term to use for it.

The C standard doesn't use that term, and I don't think it
appears in licenses referring to functions in a library.
Does it matter?

Not really; it's a terminology quibble, but sometimes those are
hard to resist.  Sort of a :-).

but the litmus test for correct vocabulary is "is it useful?".
I don't think "third-party" is useful enough in this context.


<snip>

If you take out all the functions not defined by the C standard,
the functions defined by the C standard on many systems won't work.
(I think Windows would have much the same problem, just with
differently-named functions.)

I'm pretty sure *any* OS has this "problem". In the end stdio
has to which things to devices. The Standard doesn't explain
how this occurs. Then there's of my head malloc, signals etc.
Most of the Standard Library can't be implemented without
underlying support from the implementation.

<snip>

But, um, the "C library" appears to be packaged in at least two
distinct parts already, one with the math functions and one with
the rest.  So why not further separate out the not-C-standard
extensions?  

You are drifting a bit here. You started talking about header files
now you are talking about library files. P.J.Plauger wrote an
excellent book about the implementaion of a Standrad C library (C89
only).
As I remember his standard headers were pretty clean in that they
only had stuff from the standard in them; except he had some magic
implementation defined header files which he included. But to
make the library actually work you had to link with something
implementation specific.

How will dividing the library up help the developer. I confess
I wish POSIX were cleaner but in practice it doesn't seem to make much
odds.
Wishing things were different probably isn't going to make much
difference.


Both sides in this debate, however, seem to have their biases :-),
so I thought I'd try to get a wider range of opinions .... :

(*) Is "third-party" an accurate term to apply to functions that
are not part of the C standard (but might be part of some other
standard supported by a compiler/library, such as POSIX)?

I don't think that's an accurate term to apply to OS functions
that are needed to make the C implementation work.

(*) Is there a compelling reason to avoid including anything
that's not part of the C standard library in libc (and instead
put it in a separate library)?  

The compelling reason to NOT do that is that it would break a lot
of stuff, including C.

So, replacing libc.{so,a} on an existing system with one that
doesn't include the POSIX extensions would break a lot of things.
But that doesn't really address the question of whether putting
them together in the first place was a good design, right?

I'm thinking now that comp.unix.programmer may be the right place
to ask about that.

You'll get even less sympathy there! "Why would we want to break
our Posix compliant code to make clc happy?".


If there is, does anyone know
why gcc doesn't do it that way?

gcc doesn't supply C libraries.  (It may supply some compiler support
routines like doing a 64-bit by 64-bit multiplication on machines
whose hardware doesn't do that natively.) OS vendors supply libraries.
gcc isn't a complete implementation.

Yes, quite -- obvious once it's pointed out, but not something I had
thought of ....

I *think* this is mostly on-topic, despite the references to POSIX
and gcc, since the point is mostly to explore the definition of
"third-party" and the packaging of non-standard library functions.

Do you know of a court case where you need the legal definition of
"third-party" in this context?  It seems like trying to nail down
what the definition of "is" is when you don't have a President
trying to weasel out of something.

I just think "third-party" is a bad term. I'd use "Non-standard".
or "Not C Standard"

Eh.  It's nitpicking and quibbling about terminology and like that,
but really, isn't that a big part of what people *DO* here?  Sort
of a :-).


A lot of the c.l.c. verbiage seems to be devoted to the numerical
density of cavorting nubile seraphim upon pinheads.
CBFalconer

.

Relevant Pages

  • Re: non-standard functions in libc -- bad design?
    ... should include only functions that are part of the C standard. ... C implementations often use POSIX ... why gcc doesn't do it that way? ... OS vendors supply libraries. ...
    (comp.lang.c)
  • Re: non-standard functions in libc -- bad design?
    ... discussion about whether functions that are part of the POSIX ... should include only functions that are part of the C standard. ... splitting libc in two libraries: ...
    (comp.unix.programmer)
  • Re: non-standard functions in libc -- bad design?
    ... don't think "third-party" is the right term to use for it. ... should include only functions that are part of the C standard. ... why gcc doesn't do it that way? ... OS vendors supply libraries. ...
    (comp.lang.c)
  • Re: non-standard functions in libc -- bad design?
    ... don't think "third-party" is the right term to use for it. ... should be included in a particular library file. ... As I remember his standard headers were pretty clean in that they ... I wish POSIX were cleaner but in practice it doesn't seem to make much ...
    (comp.lang.c)
  • Re: non-standard functions in libc -- bad design?
    ... The C standard imposes some requirements that an implementation of C must satisfy to be considered conforming, and other requirements that source code must satisfy in order to produce defined behavior when compiled by such implementations. ... In principle, a standard like POSIX could have taken either of two routes: it could have defined it's library to meet the requirements imposed on conforming extensions to the C standard library, or it could have defined it's library to be a third-party library independent of the C standard library, to be linked to by user code. ... Historically, this is because both standards were standardizing existing practice that pre-dated either library, and I'm not sure there were any significant better options available to the standardizers - but it makes describing the relationship between the libraries defined by the two standards somewhat confusing. ...
    (comp.lang.c)