-1

ISO:IEC 9899 standardizes the prototypes of the functions of the C standard library and describes their behavior. It specifies the identifier, the return type and the parameter(s) with its matching type(s) of a certain C standard function.

But why it does not specify the definitions - (the core how the specific functions actually do work)?

Why can a C standard library function X differ in its actual source code between f.e. the gcc compiler suite on Linux (GNU C Library), clang suite on macOS and the core system dynamic libraries for Microsoft Visual C++ on Windows? Why is it dependent upon the implementation, the operation system and the relative compiler design?

Edit: I know the question seems bad for the most of yours at the first sight but it has definitely a right to get answered, since I don´t know the reason for that yet.

I do not suggest that the ISO shall standardize the definitions because the question was closed as opinion-based - don´t get me wrong. I just ask why are things that way and want to learn from your knowledge and experience.

RobertS supports Monica Cellio
  • 14,524
  • 7
  • 33
  • 80
  • In a word, flexibility. – Shawn Mar 17 '20 at 15:34
  • 2
    Why would it need to define the implementation? Seems like that would be unnecessarily limiting. – Christian Gibbons Mar 17 '20 at 15:35
  • For example because every platform can have a different way to realize the function in an optimal way. – Paul Ogilvie Mar 17 '20 at 15:35
  • C is supposed to be extremely portable. If the C specification mandated a specific implementation, it would be extremely limiting for portability. – Some programmer dude Mar 17 '20 at 15:36
  • @ChristianGibbons What about unwanted side-effects? Wouldn´t it be more maintainable and even more portable to standardize the constructs at least? – RobertS supports Monica Cellio Mar 17 '20 at 15:37
  • @Someprogrammerdude Why would it controversy limiting the portability? I only can think of that it would increase the portability if the definitions would be at least at its constructions equal. – RobertS supports Monica Cellio Mar 17 '20 at 15:40
  • @PaulOgilvie I understand that a platform has its unique way to accomplish a specific task as efficient as possible but wouldn´t it make portable code even more reliable? – RobertS supports Monica Cellio Mar 17 '20 at 15:42
  • @Shawn Why is it more flexible? – RobertS supports Monica Cellio Mar 17 '20 at 15:45
  • 2
    So you rather have sub-optimal functions that are the same for each and every platform (in so far as it's even possible), rather than the most optimal functions possible? And while you're att it, why not limit the bit-widths of all types as well? The specification doesn't mention anything about upper limits, only lower. There are platforms where a `char` is *two* bytes, for example (but `sizeof(char)` is still equal to `1`), and `int` has grown from 16 to 32 bits on *most* platforms. Also note that the C specification doesn't mention "the stack" either, some hardware doesn't even have a stack. – Some programmer dude Mar 17 '20 at 15:45
  • 4
    @RobertSsupportsMonicaCellio -- some library functions use assembly routines; these depend on the underlying platform, and are not portable. Some library functions make use of system calls, and are not portable. The Standard Library provides a portable interface to the programmer, but the library code itself need not be portable. – ad absurdum Mar 17 '20 at 15:46
  • And regarding the portability issue, how would a function like `printf` be implemented if it's to be portable between all kinds of systems over the last 50 years that C has existed? Even since C was standardized in the late 1980's there has been so much development and diversity both for software and hardware, that a single specified implementation would soon be out of date anyway. – Some programmer dude Mar 17 '20 at 15:47

1 Answers1

7

Take strlen for example. If the ISO C standard standardized the definition of this function, it would probably look like this:

size_t strlen(char *s)
{
    size_t l = 0;
    while(s[l]) l++;
    return l;
}

This is highly inefficient. The GNU C library has implementations written in assembly and C that are very fast, but aren't portable.

Some functions may be impossible to standardize. For example, how would it define putchar, vfprintf, and fwrite? What about assembly functions like longjmp? Or "macros" like setjmp?

Other definitions may be exploited. For example, if the Standard C committee standardizes memcpy, two things would happen:

  • people can abuse the copy order, and

  • existing implementations would be invalidated.

S.S. Anne
  • 15,171
  • 8
  • 38
  • 76
  • @RobertSsupportsMonicaCellio `memcpy(s, s+1, 3);` for example is undefined behavior, if you copy forwards the result is different vs if you copy backwards. `putchar` requires OS support, and is entirely different on Windows, Linux, MacOS, BSD, etc. If you want to write code that performs thousands of string operations per second you don't want a crappy, naive `strlen`. – S.S. Anne Mar 17 '20 at 16:28