Is it undefined behaviour to call a 3rd party library function (not provided as source code)?_问答_开发者

In C is it undefined behaviour to call a 3rd party library function (not provided as source code)?

By this I mean:

Not calls to the Standard C Library.
Not calls to an additional library provided by the compiler vendor.
Not calls to a library created by me using the C compiler.
Not calls to a 3rd party library that was provided as source code and where I have compiled the library myself using the C compiler.
Not calls to a precompiled 3rd party library that I know was compiled using exactly the same C compiler that I am using.

In other words I am interested in scenarios that rely in some way on ABI compatibility开发者_如何学运维 (perhaps between different C compilers, or different versions of the same C compiler, or between compilers of different languages). The C standard has nothing to say on how to achieve ABI compatibility.

I am primarily interested in C90, which states in Section 3.16:

Undefined behavior is otherwise indicated in this International Standard by the words "undefined behavior" or by the omission of any explicit definition of behavior.

It could be argued that calling a 3rd party library function is undefined behaviour because of the "omission of any explicit definition" part of the clause above.

It could also be argued that calling a 3rd party library function is not implementation defined behaviour because the library is not provided by the compiler vendor.

If calling a 3rd party library function is indeed undefined behaviour, it means that there are 2 degrees of undefined behaviour in C, and that advice to avoid all undefined behaviour is over simplistic. How do we know which types of undefined behaviour are "OK" and which types may be viewed by the compiler writer as an opportunity to do "anything" in the interests of improving benchmark results?

EDIT: I have edited the question and the title to clarify that I am excluding cases where I compile the library myself. I don't think this changes the meaning of the question because I would argue that most 3rd party libraries are used in precompiled form.

From the C standard (again:)

5.1.1.1 Program structure
1 A C program need not all be translated at the same time. The text of the program is kept in units called source files, (or preprocessing files) in this International Standard. A source file together with all the headers and source files included via the preprocessing directive #include is known as a preprocessing translation unit. After preprocessing, a preprocessing translation unit is called a translation unit. Previously translated translation units may be preserved individually or in libraries. The separate translation units of a program communicate by (for example) calls to functions whose identifiers have external linkage, manipulation of objects whose identifiers have external linkage, or manipulation of data files. Translation units may be separately translated and then later linked to produce an executable program.

And AFAIK, exactly how translating/compiling and linking is done is beyond the standard, so, whether those libraries contain compiled code or not is up to the implementation.

A library you created using a C compiler is a 3rd party library to me.

Since you can normally use your library and it's not undefined behavior, why couldn't I also do the same if you gave it to me?

You explicitly use your library by using #include <"yourlibaray.h">, and I do the same. What you're describing doesn't have (in my opinion) much in common with the C standard section you quoted.

I would argue that relative to C, then yes, this is undefined behavior. However, it can be regarded as defined behavior because building libraries is defined by the compiler (or, more likely, the platform) you are using.

Let me explain myself - if C had a standard for building libraries, then libraries compiled under *nix would work in Windows and vice-versa. This obviously doesn't happen.

Now, considering the same platform/compiler/whatever, this can be guaranteed to work (although not by standard C) by the respective platform/compiler. I believe library-building standards are defined by the platform, not the programming language, which makes sense.

Short answer: no.

A "3rd party library" will normally include at least two components if it is designed to be used for the development of programs in the C language:

The library code (either compiled as a .dll or .so or .dylib etc., or in source code for you to compile)
.h header files, which define the functions in the library to your C compiler

The .h header files define the functions the library provides, thus ensuring you don't end up calling some code in a library with "undefined" results.

No. How could anyone possibly write code if that were so?

If you're using a third-party library, its documentation will tell you what behavior is defined and what behavior is not defined. If it has no documentation, infer its behavior from its source code. If it has no source code either, then you're on your own, and complain to the people who provided you that library.