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

In article <slrnhc66vv.shl.usenet-nospam@xxxxxxxxxxxxxxx>,
Seebs <usenet-nospam@xxxxxxxxx> wrote:
On 2009-09-30, blmblm myrealbox.com <blmblm@xxxxxxxxxxxxx> wrote:
(*) 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 wouldn't call them that, I'd call them extensions.

That would be my preferred term too. Just sayin', maybe.

(*) 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)? If there is, does anyone know
why gcc doesn't do it that way?

gcc doesn't get a vote. You might be thinking of glibc, uclibc, Berkeley
libc, klibc... gcc is just a compiler, not an implementation.

Ah. Thanks for pointing out this distinction -- obvious once you've
done so, but not something I had thought about.

(So, maybe I should try this question in comp.unix.programmer .... )

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.

A conforming implementation ought to make sure that they don't trample user
namespace.

For the record, if I write a C program that contains functions
with the same names as some POSIX-extension functions (I chose
getpid() and write()), gcc seems happy to compile and link it
without warnings or errors, and the resulting executable uses my
functions rather than the POSIX ones. That's what you mean here,
right? And those POSIX-extension functions -- the declarations
are in unistd.h rather than one of the C-standard headers, which
I'm thinking is also a sign of not-broken-ness.

Example from my own experience: I wrote a program once which worked fine if
and only if I did not break it into two modules. I had a global variable
named "end". Some nutjob had chosen the name "end" as a magic symbol marking
the end of the address space... As long as the variable was used only in
one file, I got the intended behavior.

Good story ....

Solution: The linker has a flag for making something a "weak reference",
meaning that it's linked only if nothing else with that name shows up. The
extensions are carefully made into weak references. In general, this means
that you get the expected behavior for portable code, but if you want to
request special local extensions, you can and then you have them.

I do not think there is any particular advantage to not including local
extensions as part of "the C library", as long as it's possible to build
programs with those extensions disabled in some way. (This is not entirely
consistently true in Linux these days, but it is certainly becoming more
true over time in most of the Unix-like systems I use.)

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.

Relevant Pages

  • Re: Making C better (by borrowing from C++)
    ... MS header files, or whatever, it's undefined by the standard how those ... >> possible to compile so that the method is what the compiler produces by ... all the extensions of lcc-win32 are exactly like ... is not compliant, it doesn't matter ...
    (comp.lang.c)
  • Re: Making C better (by borrowing from C++)
    ... > possible to compile so that the method is what the compiler produces by ... I would have to rewrite the 15 000 APIs that Windows ... all the extensions of lcc-win32 are exactly like ... >>BY DEFINITION in the standard itself. ...
    (comp.lang.c)
  • Is C close to the machine? (was: first-class types)
    ... in comp.lang.c and among the GCC maintainers mean the standardized ... a very abstract way that is described in the standard document and is ... GCC and GCC without optimization know quite well what is ... work on other machines if the C compiler compiles it like I intended). ...
    (comp.arch)
  • Re: C- Programming for ARM Microcontrollers
    ... Please explain what you mean by standard C ... Depending on what you are programming and what if any portability is required often you are better sticking with a compiler implementation than the C standard. ... In real world SW engineering portability is NOT a priority for the vast majority of systems An embedded system is part of something else. ... However C code should always be written in a modular style and it does make sense to try an encapsulate areas where you talk to the hardware or use some extensions. ...
    (comp.arch.embedded)
  • Re: Compaq Visual Fortran or Intel Fortran Compiler?
    ... All of those extensions are standardized in f90 and are also ... says "well of course this is standard Fortran", ... the current compiler offerings. ...
    (comp.lang.fortran)