I am making a shared library which exports a function that uses a static class instance. The shared library is intended to be dynamically loaded. However, for some reason using the static class instance causes dynamic loading to fail. I am loading the library using Poco.
//my_library.h
#ifndef MY_LIB_H
#define MY_LIB_H
#define DUMMY_MSG 1;
class SendClass
{
public:
SendClass() = default;
SendClass( const SendClass &other ) = delete;
SendClass &operator=( const SendClass &other ) = delete;
static SendClass *get_instance(){ return &singleton_instance; };
int send(){ return DUMMY_MSG; };
private:
static SendClass singleton_instance;
};
extern "C" __attribute__ ((visibility ("default"))) int send();//this is the function to be exported
inline int send()
{
return SendClass::get_instance()->send();
}
#endif // MY_LIB_H
I compile the above header file into a shared library using the command below, and put the library under /tmp/
g++ -shared -fPIC -o libexp.so my_library.h
And then I attempt to load the library in my main program
//main.cpp
#include "Poco/SharedLibrary.h"
using namespace std;
typedef int(*SENDFUNC)();
int main
(
int argc,
char **argv
)
{
Poco::SharedLibrary lib;
lib.load( "/tmp/libexp.so" ); //crashes here!
SENDFUNC send_func = (SENDFUNC)lib.getSymbol("send");
int msg = send_func();
return 0;
}
The program crashes at the line "lib.load( "/tmp/libexp.so" );" with the following message:
terminate called after throwing an instance of
'Poco::LibraryLoadException' what(): Cannot load library
However, if I change the body of SendClass::get_instance to the following, the dynamic loading is completed successfully
//if SendClass::get_instance is implemented as follows, dynamic loading succeeds
static SendClass *get_instance(){ return new SendClass; };
So why does using a static instance cause dynamic loading to fail?
As per #ALX23z's advice I solved the problem by adding the following cpp file
//my_library.cpp
#include "my_library.h"
SendClass SendClass::singleton_instance;
Related
I am trying to create a program that uses plugins in C++ to get some experience with importing and exporting functions from .dll and .so libraries. For simplicity's sake let's only use .dll libraries here.
What I'm trying to do is to make the communication between the plugin and the main program that loaded it "two-way", meaning the main program can call functions from the plugin (this is solved) and the plugin should be able to call functions from the main program (this I'm having trouble with).
I currently am able to create a .dll where I exported the functions with extern "C" {} and __declspec(export).
TestPlugin.h
#pragma once
extern "C" {
__declspec(dllexport) const char* pluginName();
__declspec(dllexport) void onLoad();
__declspec(dllexport) void onShutdown();
}
TestPlugin.cpp
#include "TestPlugin.h"
#include <iostream>
const char * pluginName()
{
return "Test Plugin";
}
void onLoad()
{
std::cout << "onLoad() called!" << std::endl;
}
void onShutdown()
{
std::cout << "onShutdown() called!" << std::endl;
}
I am then loading this test plugin with the following (shortened) code. I removed the error checking and console output.
Plugin.h
#pragma once
#include <filesystem>
#include <iostream>
#include <windows.h>
class Plugin
{
private:
typedef const char*(*pluginNameType)();
typedef void(*onLoadType)();
typedef void(*onShutdownType)();
HINSTANCE m_lib;
public:
Plugin(std::filesystem::path filename);
~Plugin();
pluginNameType pluginName;
onLoadType onLoad;
onShutdownType onShutdown;
};
Plugin.cpp
#include "Plugin.h"
Plugin::Plugin(std::filesystem::path filename)
{
m_lib = LoadLibrary(filename.wstring().c_str());
pluginName = (pluginNameType)GetProcAddress(m_lib, "pluginName");
onLoad = (onLoadType)GetProcAddress(m_lib, "onLoad");
onShutdown = (onShutdownType)GetProcAddress(m_lib, "onShutdown");
}
Plugin::~Plugin()
{
FreeLibrary(m_lib);
}
What I can do now is to call the functions in the plugin (TestPlugin.cpp) from my main program.
main.cpp
Plugin *plugin = new Plugin("pathToDLLGoesHere");
plugin->onLoad();
plugin->onShutdown();
What I would like to do now is to also enable the test plugin I just loaded to have access to functions that are defined in the main program. So let's say in my main.cpp I have something like this ...
main.cpp
int testCall(int val) {
return val + 1;
}
int main()
{
...
return 0;
}
... how would I be able to call the testCall() from the test plugin?
Would it be as simple as to send the function pointer to the plugin and use it? Or do I need to take a different approach here? Thank you for your help!
I have figured out how this works. You can also use extern "C" {} and __declspec(dllexport) to export functions from your main program so the DLLs can see them and when you get the handle of your main program in the DLL, the functions can be called.
In one of your headers in your main program you export the function.
main.h
extern "C" {
__declspec(dllexport) int testCall(int val);
}
main.cpp
int testCall(int val) {
return val + 1;
}
In my test plugin header I created a handle for the main program and a definition for the function I am trying to call from main.
TestPlugin.h
#pragma once
#include <windows.h>
HINSTANCE app;
int(*testCall)(int val);
...
In the body I then assign the handle (calling GetModuleHandle with a nullptr will give you the handle of your program) and then get the exported function from my main program.
TestPlugin.cpp
app = GetModuleHandle(nullptr);
testCall = (int(*)(int val))GetProcAddress(app, "testCall");
After that, I can just call the function.
std::cout << testCall(5) << std::endl;
I am trying to export a function template with a static variable in the definition.
.dll/Foo.h:
#ifdef _DLL
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif
class API Foo
{
public:
template<typename T>
static T& Get()
{
static T _instance;
return _instance;
}
static void Set();
}
I want the calls made by the .dll and .exe to refer to the same "_instance" object. I know I can do that by defining the static variable in the .cpp. But in this case i am dealing with templates so i am kind of stuck.
Edit:
Example of what is happening..
.dll/Foo.cpp:
void Foo::Set()
{
Foo::Get<int>() = 10;
}
.exe/main.cpp:
int main()
{
auto & x = Foo::Get<int>();
x = 3;
std::cout << x; // 3
Foo::Set();
std::cout << x; // 3 (I want it to be 10)
}
you need separate mark every template with API (__declspec(dllexport) or __declspec(dllimport)) and not inline it in class code.
Foo.h file is:
#ifdef _DLL
#define API __declspec(dllexport)
#else
#define API __declspec(dllimport)
#endif
class API Foo
{
public:
template<typename T>
API static T& Get();
static void Set();
};
note that we separate mark Get() with API despite all Foo class also marked with API (class mark have no effect on template function by fact, so need it mark separate). and no implementation of Get here - exported functions anyway can not be inline.
so dll code (Foo.cpp) must look like:
#include "foo.h"
template<typename T>
API T& Foo::Get()
{
__pragma(message("__imp_" __FUNCDNAME__)) // for debug
static T _instance;
return _instance;
}
void Foo::Set()
{
Foo::Get<int>() = 10;
}
note we again explicitly use API (__declspec(dllexport)) in implementation of function body. this is critical important - compiler not warning you, if you skip API here, but without this - Get will be not exported.
for sure that at this point all correct - copy string produced by __pragma(message("__imp_" __FUNCDNAME__)) (it will be look like __imp_??$Get#H#Foo##SAAEAHXZ) and search exactly (symbol to symbol) this string in created .lib file - after you build dll. if it exist - all ok, otherwise no sense continue (with exe)
and in exe :
#include "../foo_dll/foo.h"
Foo::Get<int>() = 3;
Foo::Set();
if (Foo::Get<int>() != 10)
{
__debugbreak();
}
I am trying to use spdlog in a project involving a library under windows.
I create two loggers. One for the app using the library, one for the library itself.
The library's logger is created from the app but when the library want to add a message, it crash.
Following is an simplified example.
The library
libclass.h
#ifndef LIBCLASS_H
#define LIBCLASS_H
#include <spdlog/spdlog.h>
#ifdef WIN32
# ifdef BUILD_APPLIB_SHARED
# define APPLIB_EXPORT __declspec(dllexport)
# else
# define APPLIB_EXPORT
# endif //BUILD_APPLIB_SHARED
#else
# define APPLIB_EXPORT
#endif // WIN32
class APPLIB_EXPORT LibClass
{
public:
LibClass();
~LibClass();
static std::string loggerName();
void testLog();
private:
std::shared_ptr<spdlog::logger> m_logger;
};
#endif //LIBCLASS_H
libclass.cpp
#include "libclass.h"
const std::string myLoggerName = "lib_logger";
LibClass::LibClass()
{
m_logger = spdlog::get(myLoggerName);
}
LibClass::~LibClass()
{ }
std::string LibClass::loggerName()
{
return myLoggerName;
}
void LibClass::testLog()
{
m_logger->info("Log from library");
}
The application
main.cpp
#include <spdlog/spdlog.h>
#include <applib/libclass.h>
void logtest()
{
auto logger = spdlog::get("app_logger");
logger->info("Log from application");
}
int main(int argc, char *argv[])
{
// create loggers
auto appLogger = spdlog::stdout_logger_mt("app_logger");
auto libLogger = spdlog::stdout_logger_mt(LibClass::loggerName());
// log from app
logtest();
// log from lib
LibClass lc;
lc.testLog();
return 0;
}
Spdlog uses a singleton registry for keeping track of available loggers. You get one instance of that registry per dll and exe though.
When you create the logger in the exe, it is added to the exe's registry but not the dlls. When you use spdlog::get(myLoggerName) in your dll, you are querying the registry of the dll which does not contain the "lib_logger" and thus you are getting a null shared_ptr.
Possible solutions are: create the lib_logger in the lib instead of the exe if you are only using it in the dll anyway, or pass the logger from the exe to the dll and call spdlog::register_logger with it inside the dll before calling spdlog::get(myLoggerName). Then you can use the same logger from both the exe and the dll.
An example how one can register loggers across dll boundaries can be found at https://github.com/gabime/spdlog/wiki/How-to-use-spdlog-in-DLLs
Or an example using your code:
The library
libclass.h
#ifndef LIBCLASS_H
#define LIBCLASS_H
#include <spdlog/spdlog.h>
#ifdef WIN32
# ifdef BUILD_APPLIB_SHARED
# define APPLIB_EXPORT __declspec(dllexport)
# else
# define APPLIB_EXPORT
# endif //BUILD_APPLIB_SHARED
#else
# define APPLIB_EXPORT
#endif // WIN32
class APPLIB_EXPORT LibClass
{
public:
LibClass();
~LibClass();
static std::string loggerName();
void testLog();
private:
std::shared_ptr<spdlog::logger> m_logger;
};
APPLIB_EXPORT void registerLogger(std::shared_ptr<spdlog::logger> logger);
#endif //LIBCLASS_H
libclass.cpp
#include "libclass.h"
const std::string myLoggerName = "lib_logger";
LibClass::LibClass()
{
m_logger = spdlog::get(myLoggerName);
}
LibClass::~LibClass()
{ }
std::string LibClass::loggerName()
{
return myLoggerName;
}
void LibClass::testLog()
{
m_logger->info("Log from library");
}
APPLIB_EXPORT void registerLogger(std::shared_ptr<spdlog::logger> logger)
{
spdlog::register_logger(logger);
}
The application
main.cpp
#include <spdlog/spdlog.h>
#include <spdlog/sinks/stdout_sinks.h>
#include <applib/libclass.h>
void logtest()
{
auto logger = spdlog::get("app_logger");
logger->info("Log from application");
}
int main(int argc, char* argv[])
{
// create loggers
auto appLogger = spdlog::stdout_logger_mt("app_logger");
auto libLogger = spdlog::stdout_logger_mt(LibClass::loggerName());
registerLogger(libLogger);
// log from app
logtest();
// log from lib
LibClass lc;
lc.testLog();
return 0;
}
Your example works fine on the current version of spdlog:
$ g++ -std=c++11 main.cpp libclass.cpp -I .
$ ./a.out
[2015-08-24 07:29:04.502] [app_logger] [info] Log from application
[2015-08-24 07:29:04.502] [lib_logger] [info] Log from library
Same when using a shared library:
# CMake config:
project(TEST)
include_directories(.)
add_library(class SHARED libclass.cpp)
target_compile_options(class PUBLIC -std=c++11)
add_executable(main main.cpp)
target_link_libraries(main class)
Results:
$ cmake .
$ make
$ ldd main
...
libclass.so => ...
$ ./main
[2015-08-25 08:57:51.864] [app_logger] [info] Log from application
[2015-08-25 08:57:51.864] [lib_logger] [info] Log from library
Make sure that you link with a DLL runtime on Windows.
I am a real C++ noob, so please be patient with me. First lets set the stage.
I have a C++ source in binary.cpp that compiles to a binary which looks like:
# include "lotsofheaders.h"
int main(int argc, char* argv[])
{
int errorcode = FOOBAR_GLOBAL_UNKNOWN;
// foobar instanciation
Foobar foobar();
// multiple calls to :send_auth passing in foobar instance
errorcode = send_auth(getX(), getY(), foobar);
errorcode = send_auth(getX(), getY(), foobar);
errorcode = send_auth(getX(), getY(), foobar);
return errorcode == FOOBAR_OK ? EXIT_SUCCESS : EXIT_FAILURE;
}
The send_auth method is loaded from another object code file and it gets passed an instance of foobar. The reason is, Foobar comes from an API object that I do not have the source of and which MUST NOT be instantiated more than once.
Since main is called only once, everything works as expected: There is only one instance of Foobar and send_auth can be called multiple times.
The binary is not of any use for me, I need a shared object library that does the same. It creates only one instance of Foobar and exposes an external interface method send_with_auth that can be called multiple times after my shared object lib was loaded.
My library code in library.cpp looks some like this:
# include "lotsofheaders.h"
# include "library.h"
const char* send_with_auth(const char* X, const char* Y){
std::string x(X);
std::string y(Y);
int result = send_auth(x, y, 'some Foobar singleton');
return true;
}
Since I load my shared object library via Ruby FFI I need some C-Style headers in library.h for my lib:
extern "C" {
const char* send_with_auth(const char* X, const char* Y);
}
Now with stage set I have to create an instance of Foobar exactly once inside my library and pass it into every call of send_auth to not get a memory violation error from Foobar.
Here's my (overly complex) attempt with a singleton as I understood it. There is a new library.h like so:
extern "C" {
class Singleton
{
private:
static bool instanceFlag;
static Singleton *single;
Singleton()
{
//private constructor
}
public:
static Foobar* fo;
static Singleton* getInstance();
~Singleton()
{
instanceFlag = false;
}
};
const char* send_with_auth(const char* X, const char* Y);
}
And there is this implementation library.cpp:
# include "lotsofheaders.h"
# include "library.h"
bool Singleton::instanceFlag = false;
Singleton* Singleton::single = NULL;
Singleton* Singleton::getInstance()
{
if(! instanceFlag)
{
single = new Singleton();
instanceFlag = true;
// bringing up my Foobar instance once and only once
Foobar fo;
single->fo = &fo;
return single;
}
else
{
return single;
}
}
const char* send_with_auth(const char* X, const char* Y){
std::string x(X);
std::string y(Y);
Singleton *single;
single = Singleton::getInstance();
int result = send_auth(x, y, *single->fo);
return true;
}
This code at least compiles and I can bind together everything to a shared object library. Now when I load that library in an external process (a Ruby module using Ruby FFI in my case) I always get the error:
Could not open library '/some/path/libfoobar.so': /some/path/libfoobar.so: undefined symbol: _ZN9Singleton2erE (LoadError)
I'm quite sure that my compiling/binding/stripping process from library.o to libfoobar.so is ok, because it succeeds in other cases. I am quite sure that I misunderstand C++'s singleton concept here. I wonder how I can achive my goal: create only one instance of Foobar inside my shared object library and pass it into every call of the only methods my library exposes to the outside.
Can anyone help on that?
Regards Felix
Update
Using the CommandlineParser in the library was stupid. In fact it simply returned two C-strings. The API library path and a log dir. With that I recreated a namespace:
namespace
{
char* home("/path/to/api/libs");
char* log("/tmp");
Foobar foobar(home, log);
}
That leads to a seg fault in the moment when I load the library. In contrast to that I can put these lines into my function directly:
const char* send_with_auth(const char* X, const char* Y){
std::string x(X);
std::string y(Y);
char* home("/path/to/api/libs");
char* log("/tmp");
Foobar foobar(home, log);
int result = send_auth(x, y, &foobar);
return true;
}
Everything works fine here except the fact that a second call to send_with_authlets crash everything cause Foobar is instantiated again.
Update 2:
Finally I solved it even simpler, used a globally available bool switch to initialize my Foobar instance only once:
namespace baz{
bool foobarInitialized = false;
}
const char* send_with_auth(const char* certificatePath, const char* certificatePin, const char* xmlData){
std::string certificate_path(certificatePath);
std::string certificate_pin(certificatePin);
std::string xml_data(xmlData);
Foobar *foobar_ptr;
if (! baz::foobarInitialized) {
char* home_dir("/path/to/api/lib");
char* log_dir("/tmp");
foobar_ptr = new Foobar(home_dir, log_dir);
baz::foobarInitialized = true;
}
int result = send_auth(x, y, foobar_ptr);
return xml_data.c_str();
}
Now I can call send_with_auth endlessly without having Foobar instantiated more than once. Done!
So my first suggestion is to do
The simplest thing that could possibly work
and get rid of the singleton entirely. Just create a global Foobar object in your library:
// library.cpp
namespace {
Foobar global_foobar;
}
I've put it in an anonymous namespace so it won't clash with any other symbol called "global_foobar" in the main executable, or another library.
This does mean it can only be accessed from within library.cpp. If you have more than one .cpp file linked into your lib, you'll need something marginally more elaborate:
// library_internal.h
namespace my_unique_library_namespace {
extern Foobar global_foobar;
}
// library.cpp
#include "library_internal.h"
namespace my_unique_library_namespace {
Foobar global_foobar;
}
// library_2.cpp
#include "library_internal.h"
using my_unique_library_namespace::global_foobar;
I am creating programs using C. However, I require to use a lot of libraries that have API's only for C++. So, is it possible that I can create a shared object in C++ and then access its functionality using C?
The only data I would be passing and returning would be C compatible data types.
Converting or migrating to cpp is not an option here.
If it is not possible to interface these codes, how do I get information from C++ code to C code?
I tried calling C++ functions from C, but I get errors during linking when I include <string>. So when I call C++ functions from C, should I only use that code which will be C compiler compatible?
C++ header cppfile.hpp
#ifndef CPPFILE_H
#define CPPFILE_H
#ifdef __cplusplus
extern "C" {
#endif
extern int myfunction(const char *filename);
#ifdef __cplusplus
}
#endif
#endif
C++ file cppfile.cpp
#include "cppfile.hpp"
#include <string>
int myfunction(const char *filename) {
String S(filename);
return 0;
}
C file cmain.c
#include "cppfile.hpp"
int main(int argc, char **argv)
{
int i = myfunction(argv[1]);
printf("%d\n", i);
return 0;
}
Compiling:
gcc -c cmain.c
g++ -fPIC -shared -o cppfile.so cppfile.cpp
You want something more like this (and here I will use a slightly more meaningful example):
C/C++ header - animal.h
#ifndef ANIMAL_H
#define ANIMAL_H
#ifdef __cplusplus
class Animal {
public:
Animal() : age(0), height(0) {}
Animal(int age, float height) : age(age), height(height) {}
virtual ~Animal() {}
int getAge();
void setAge(int new_age);
float getHeight();
void setHeight(float new_height);
private:
int age;
float height; // in metres!
};
#endif /* __cplusplus */
#ifdef __cplusplus
extern "C" {
#endif
struct animal; // a nice opaque type
struct animal *animal_create();
struct animal *animal_create_init(int age, float height);
void animal_destroy(struct animal *a);
void animal_setage(struct animal *a, int new_age);
void animal_setheight(struct animal *a, float new_height);
int animal_getage(struct animal *a);
float animal_getheight(struct animal *a);
#ifdef __cplusplus
}
#endif
#endif /* ANIMAL_H */
C++ animal implementation file - animal.cpp
#include "animal.h"
#define TO_CPP(a) (reinterpret_cast<Animal*>(a))
#define TO_C(a) (reinterpret_cast<animal*>(a))
void Animal::setAge(int new_age) { this->age = new_age; }
int Animal::getAge() { return this->age; }
void Animal::setHeight(float new_height) { this->height = new_height; }
float Animal::getHeight() { return this->height; }
animal *animal_create() {
animal *a = TO_C(new Animal);
return a;
}
animal *animal_create_init(int age, float height) {
animal *a = TO_C(new Animal(age, height));
return a;
}
void animal_destroy(animal *a) {
delete TO_CPP(a);
}
void animal_setage(animal *a, int new_age) {
TO_CPP(a)->setAge(new_age);
}
void animal_setheight(animal *a, float new_height) {
TO_CPP(a)->setHeight(new_height);
}
int animal_getage(animal *a) {
TO_CPP(a)->getAge();
}
float animal_getheight(animal *a) {
TO_CPP(a)->getHeight();
}
C client code - main.c
#include "animal.h"
#include <stdio.h>
int main()
{
// 6'0" 25yo (perhaps a human? :P)
struct animal *a = animal_create(25, 1.83);
animal_setage(a, 26); // birthday
printf("Age: %d\nHeight: %f", animal_getage(a), animal_getheight(a));
animal_destroy(a);
return 0;
}
C++ client code - main.cpp
#include "animal.h"
#include <iostream>
int main()
{
// 6'0" 25yo (perhaps a human? :P)
Animal* a = new Animal(25, 1.83);
a->setAge(26); // birthday
std::cout << "Age: " << a->getAge() << std::endl;
std::cout << "Height: " << a->getHeight();
delete a;
return 0;
}
So when you compile the library, you compile animal.cpp with a C++ compiler. You can then link to it with C code, and use the animal_xxx functions.
Note the use of struct animal and Animal. Animal is a normal C++ type. It's exactly what it looks like. struct animal, on the other hand, is an "opaque" type. That means that your C program can see it's there, and can have one, but it doesn't know what is inside it. All it knows is that it has a function that takes a struct animal*.
In a real library you will want to have customisation points for memory allocation. So assuming this is the library libjungle, you probably want at least jungle_setmalloc and jungle_setfree with sensible defaults. You can then set up the global new and delete in libjungle's C++ code to use these user-defined functions.
This is entirely possible. Here is how, quickly:
1.) You have a header.h with a C API that doesn't include any Cplusiness.
#ifndef MIXEDCCPP_H
#define MIXEDCCPP_H
#ifdef __cplusplus
extern "C" {
#endif
#include <stdint.h> // Any C-compatible headers will go here.
// C API goes here. C Functions can't contain any CPPiness.
void myclass_setName( void *pClassObj, const char *pName, int nameLen );
#ifdef __cplusplus
}
#endif
#ifdef __cplusplus
// Stuff that is only compatible with CPP goes here
// __cplusplus section won't get processed while compiling C files.
#include <vector> // CPP headers.
class MyClass {
// Classes etc.
};
#endif // #ifdef __cplusplus
#endif // MIXEDCCPP_H
Then in the .cpp, you simply create some C-API functions that can even include CPP right in them:
#include "mixedccpp.h"
extern "C" {
// C API goes here. C Functions can't contain any CPPiness in their prototypes.
void myclass_setName( void *pClassObj, const char *pName, int nameLen )
{
// But CPP knowledge can go inside the function - no problem, since this is a CPP file.
MyClass *pMyClass = static_cast<MyClass *>(pClassObj);
pMyClass->setName( pName, nameLen );
}
} // #extern "C"
// CPP Stuff goes here... or vice-versa.
In your case, you don't actually need any CPP code declared in your header since you are calling external libraries. But you need to create C-compatible functions in your CPP file which can call out to CPP libraries. Use extern "C" for those functions that need to be called from C files, and then use C-structs instead of classes and, if classes are needed, use void * to point to them and then cast them back to their class from the C function any time you need to access them. A standard makefile should be able to compile this just fine, assuming it compiles .cpp files as .cpp and understands extern "C" {}
Your C code cannot use the C++ header <string>. You have to ensure that the functions in the C++ API that are to be called from C are declared extern "C" (as you have), and use only types recognized by a C compiler (as you have).
You also need to link with the C++ compiler if any of your code is in C++. You can do it otherwise if you're prepared to spend a lot of energy getting the loader options right, but it is far simpler just to use the C++ compiler:
gcc -c cmain.c
g++ -fPIC -shared -o cppfile.so cppfile.cpp
g++ -o cmain cmain.o cppfile.so
Of course, you need to:
Add #include <stdio.h> in cmain.c.
Use std::string S(filename); in cppfile.cpp.
Also, if the program is invoked without arguments, you get:
$ ./cmain
terminate called throwing an exceptionAbort trap: 6
$ ./cmain x3
0
$
You need to protect against misuse, even in test programs.