Talk:C standard library/Archive 1

(random heading)
(inserted for readability Rursus dixit. ( m bork3 !) 13:23, 24 July 2010 (UTC))

How is the article C standard library supposed to be distinguished from the article ANSI C standard library ? Should they be merged? Bevo 15:51, 2 Jan 2004 (UTC)

It turns out that Talk:ANSI C standard library has some discussion about how the two articles can co-exist. I am somewhat convinced. I suppose "standard" for this article just means whatever an implementation vendor makes available with the #include   syntax. Bevo 15:59, 2 Jan 2004 (UTC)

Don't have time at the moment (might later), but it'd pretty things up some if the header files mentioned at the bottom of this article were linked to the subsections of ANSI C standard library that list the basic functions in those headers. MrZaius


 * Much of the C standard library has been shown to have been well-designed.

I disagree with this comment, and I feel it is POV. Some other notable people, such as Steve Maguire (author of "Writing Solid Code"), disagree, citing things like cryptic function names, inconsistent order of arguments to functions (for instance, in some functions, the first argument is a file pointer, and in others, it's the last), and so on. Other points are more debatable, e.g., realloc can function as an allocator, reallocator, and deallocator, all in one -- some feel this is good, and some don't. I'd revise or omit the statement, but don't really know the best way to do so without using weasel words. - Furrykef 11:32, 16 Nov 2004 (UTC)

merge from C Run-Time Library
I'm proposing a merge from the C Run-Time Library to the C standard library.

The new text for "C standard library" would be something like this:

The C Run-Time Library includes routines which may help the compiler itself with the program at runtime. The code that initializes the process for the operating system, for example, before calling  lives in the C Run-Time Library for a given vendor's compiler. The Run-Time Library code might help with other language feature implementations, like handling uncaught exceptions or implementing floating point code.

The C standard library only documents that the specific routines mentioned in this article (C standard library) are available, and how they behave. The compiler implementer might depend on additional implementation-level functions to be avaialble, and is likely to package both the their run-time library and the C standard library in the same module, since they're both likely to be needed by any program built with their toolset.

What do you think?

-- Mikeblas 23:37, 31 December 2005 (UTC)
 * With no objections, I've performed the proposed merge. -- Mikeblas 21:32, 8 January 2006 (UTC)

GTK+
In the section "ANSI Standard", it says the GNOME project developed the GTK+ graphics toolkit, whereas the GTK+ was created for GIMP project, and is (more than anything) a sister project to the GNOME project. After all, GTK+ stands for the GIMP Toolkit. I think it's a stretch to say that it is developed by the GNOME project.

I am pretty sure the same goes for Glib. I don't know if those are worth correcting, though.

Ibjt4ever 02:18, 4 September 2006 (UTC)

Template
I want to do a guide for strarg.h, but I need the C libraries template. Any help?

ISO vs. ANSI
The article should refer to "ISO C" rather than "ANSI C", since the current (and presumably, future) standard of the language and library are specified and controlled by ISO, not ANSI. ANSI C (C89) was simply the first incarnation of a standardized C language, and was quickly adopted internationally as an ISO standard (C90). The current standard is ISO C 9899:1999 (C99). — Loadmaster 17:53, 5 July 2007 (UTC)

There Are More Compilers Which Only Comply With ANSI C Not ISO C There IS A Difference http://en.wikipedia.org/wiki/ANSI_C —Preceding unsigned comment added by 71.66.124.32 (talk) 03:24, 9 June 2010 (UTC)

GNU C library and Linux
The article mentions that the GNU C library is used in Linux -- this is not true. It is true that operating systems which use Linux as a kernel often uses the GNU C library as their C library, but the kernel does not contain any C library at all and hence does not contain the GNU C library either. I suspect the same is true for HURD (being that it is a kernel). What was likely ment with the statement is that the GNU C library is the default C library in the GNU based operating systems, which includes most "linux" distributions and "HURD" (which is likely refering to the GNU operating system, which uses/will use HURD as the kernel).

See gnu.org for discussions on the confusion about Linux and GNU. In the meantime, I will correct the error -- if you have good argument for reverting it, it had better not be some variant of "people think their operating system is Linux, even if it is GNU". —Preceding unsigned comment added by 80.167.145.223 (talk) 14:56, 17 January 2010 (UTC)


 * 1) For more wonkery in a similar vein read here. 82.204.68.130 (talk) 15:43, 15 June 2010 (UTC)


 * I'll put that term on my mind. Thanks! ;^#) Rursus dixit. ( m bork3 !) 13:25, 24 July 2010 (UTC)

Regarding edit 41909550 by User:Arbanbeans
One example is not enough to give an impression of a strong trend as i meant to when writing this. Also, they do change it "invariably": why knowingly introduce decades-old security and stability flaws into a newly developed application - moreover, deliberately carve them in stone at the interface designing stage? Well, since we can't speak for all the past, present and future projects with a C-like interface, the words "tend to" might be more appropriate. &mdash; Vano 06:07, 4 April 2011 (UTC)