Tag Archives: c++
Polymorphism in Plain C
Here we go through the steps required to implement polymorphic interfaces in plain C. We use function pointers for this task, hidden behind generic functions we define for the interface itself.
To demonstrate the technique, we implement a simple queue of string pointers. This entry is about the generic interface so some deficiencies and possibly bugs in the actual implementation may pass us by. Please write the author or comment on the post if you spot errors in the implementation.
First we define the interface we’re going to use. We start off by defining a struct with the function pointers we need.
struct queue {
void *secret;
void (* enqueue)( struct queue *, char * );
char * (*dequeue)( struct queue * );
bool (*empty)( struct queue * );
struct queue * (* delete)( struct queue * );
};
The void *secret is what we use in the implementation to keep track of our secret data structure. The rest are the function pointers we need to define for each implementation.
Here we use direct function pointers for all of the functions. We could also put the pointers into a separate struct for easier sharing, or at least smaller concrete objects, but we leave that optimization as an exercise for the dedicated reader.
Continue reading Polymorphism in Plain C
MariaDB: Get the Load Average
Here we present a simple user defined function in C, that returns the load average.
The function returns a string formatted like top‘s because C functions cannot return individual rows nor an array of reals.
The following code can be viewed as an example code for user defined functions in C — or alternatively as an example of how to use snprintf() correctly.
Building OpenSSL with OpenWatcom on ArcaOS: First Porting Effort
I have previously written about my OpenSSL port to OS/2. Here I go over the first C code changes that make it compile with OpenWatcom 1.9.
As previously mentioned, I’m doing this on ArcaOS; so some Unix-ism will be present in the build system. This is apparently unavoidable, and fortunately, ArcaOS already comes with a lot of Unix ports; both out of the box and installed through yum (or the Arca Noae Package Manager).
The following changes leave us with a port that builds for the most part. Some parts will need more changes before they are strictly “correct” and we’ll return to those later.
Continue reading Building OpenSSL with OpenWatcom on ArcaOS: First Porting Effort
Using the OpenWatcom Assembler with Jam
I’ve previously covered the OS/2 port of Perforce Jam.
Here we’ll go over what it takes to make Jam know about the OpenWatcom assembler, Wasm.
First we can look at the Jambase file, in the source where we find the
actions As
{
$(AS) $(ASFLAGS) $(ASHDRS) -o $(<) $(>)
}
and we see that Jam has a few variables related to assembler files.
The Jamfile
First, we tell Jam that our assembler is Wasm.
AS = wasm ;
Then we redefine the As actions to be
actions As
{
$(AS) -q $(ASFLAGS) $(ASHDRS) -fo=$(<) $(>)
}
where -fo=$(<) is the output file, and $(>) the input file. We could also have used the newer syntax, $(1) and $(2). The -q tells Wasm to operate quetly; it means we won’t see the copyright information every time we run Jam; only the nice As file.asm output.
Now, we can make use of these changes with
Main hello.exe : hello.c sum.asm ;
The Sources
The source files we mentioned above are hello.c and sum.asm.
Here is hello.c
#include <stdio.h>
int sum( int a, int b );
int main( int argc, char *argv[] ) {
printf( "Hello, %d.\n", sum( 3, 5 ) );
return 0;
}
And here is sum.asm
.386
.model flat
.code
PUBLIC sum_
sum_ PROC
add eax, edx
ret
sum_ ENDP
END
These two files demonstrate how we can declare a function in C, and then define it in an assembly file. We are using the register calling convention of OpenWatcom. The first argument is in eax, the second in edx and the return value is again in eax. That means we don’t have to worry about stack manipulation at all, in a simple function like sum(). OpenWatcom appends _ to function names with the register convention, so we have to append it also in the .asm file.
With the above Jamfile, we just run
jam
and our demonstration program is built and linked properly for us.
Running the Demo
Now, when we run
hello
on the command line, we see
Hello, 8.
Final Words
This has been written as Jamfile demonstration, but it can also be viewed as a demonstration of the register calling in OpenWatcom.
Do you need professional help with OS/2? Write to johann@myrkraverk.com.
Building Jam 2.6 on OS/2 with OpenWatcom
These instructions pertain to ArcaOS 5.0.1 and OpenWatcom 1.9. Any other OS/2 versions and compilers may behave slightly differently; your mileage may wary.
Here we will go through the process of porting Perforce Jam 2.6, released in 2014. At the time of writing, the source can be downloaded from the Perforce website.
There is also FT Jam, from the FreeType project, which is quite possibly more advanced, even though it’s based on Perforce Jam 2.5. and hasn’t been updated since about 2006, apparently.
Haiku Jam is also worth checking out.
Copyright and disclaimers
Jam has the following copyright:
Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
License is hereby granted to use this software and distribute it freely, as long as this copyright notice is retained and modifications are clearly marked.
ALL WARRANTIES ARE HEREBY DISCLAIMED.
Furthermore, no work has been done to insure the OS/2 port is fit for any particular purpose, except to ensure it successfully builds itself.
The Makefile
The settings at the start should look like this.
CC = wcl386 CFLAGS = EXENAME = jam0.exe TARGET = -fe=$(EXENAME)
That is, the compiler is wcl386, with no special C flags, and the name is jam0.exe without the period and slash. The -fe= tells wcl386 what to name the executable file; possible mnemonic: file executable.
Optionally add wtouch all as the final command in the “all” rule, or build with -c; otherwise WMake will complain the “all” target has not been built.
That takes care of the Makefile.
The make1.c file
There are minor changes in the make1.c file, because it unconditionally calls unlink() and we “fix that” with these macros at the start.
# ifdef OS_OS2 # define INCL_DOSFILEMGR # include <os2.h> # define unlink DosDelete # endif
You will need to remove the READ ONLY flag from the file before it
can be saved.
attrib -r make1.c
The execunix.c file
In this file, there are some major changes; so to speak.
At the top we add
# define INCL_DOSPROCESS # define INCL_DOSFILEMGR # include <os2.h> # define unlink DosDelete
inside the OS/2 section, because it also calls unlink() unconditionally. And we also need to get access to process information, to get the PID.
The complete section shoudl look like this:
# ifdef OS_OS2 # define USE_EXECNT # include <process.h> # define INCL_DOSPROCESS # define INCL_DOSFILEMGR # include <os2.h> # define unlink DosDelete # endif
After this change, on line 188, is a
# ifdef USE_EXECNT
inside which is an NT call GetCurrentProcessId() which we port to use DosGetInfoBlocks() instead.
So at the start of the scope, we declare two new pointers, to the thread and process structure respectively.
TIB *thread;
PIB *process;
And before sprintf() that refers to the PID, we call
DosGetInfoBlocks( &thread, &process );
while inside the sprint() call itself, where GetCurrentProcessId() used to
be, we have
process->pib_ulpid
instead. The complete function call now looks like
sprintf( cmdtab[ slot ].tempfile, "%s\\jam%lut%d.bat", tempdir, process->pib_ulpid, slot );
where we have carefully updated the format specification to reflect unsigned long %lu, instead of integer %d. Even though integers and longs are the same size on 32bit OS/2, there’s no reason to be sloppy about format specifiers in the printf() family of functions.
You will also need to remove the read only bit before saving the file.
attrib -r execunix.c
The jamgram.c and parse.c files
These source files will have some warning about undeclared function names. This is ok, and is not worth fixing just to get Jam working on OS/2. Maybe later, and particularly if Perforce is willing to accept contributions, it may turn out to be a worthwhile effort to fix.
This takes care of the source files.
Building It
Now do
wmake -u -c
in a command prompt, and Jam will bootstrap itself. The Jam built object files and executable will be in a subdirectory called bin.os2x86 so don’t be surprised if you only see the jam0.exe file at first.
On modern hardware, the complete build takes only a few seconds.
The -u is for unix compatibility mode, and allows WMake to understand the backslash line continuation syntax; lines that end with \ are joined. Without this, there will be an error.
As mentioned previously, the -c is to stop WMake from complaining that “all” has not been built. Leave it out of you added wtouch all to the rule.
Installation
To install Jam, just copy the jam.exe file into c:\usr\local\bin, which you may have to create first, or wherever your %UNIXROOT% is.
mkdir c:\usr\local
mkdir c:\usr\local\bin
copy bin.os2x86\jam.exe c:\usr\local\bin\
It is normal that the mkdir commands fail when the directory exists already.
Alternatively, you can write the commands like this, in case your
UNIXROOT is not C:.
mkdir %UNIXROOT%\usr\local
mkdir %UNIXROOT%\usr\local\bin
copy bin.os2x86\jam.exe %UNIXROOT%\usr\local\bin
Final Words
Congratulations, now you have completed the build and installation of Perforce Jam 2.6.
Happy building.
Do you need professional assistance with OS/2? Write to johann@myrkraverk.com.
Parsing Command Line Parameters with Yacc & Flex
This is a repost from 2012, but my old blog site disappeared.
Every once in a while someone comes along and asks how to parse command line parameters with Yacc & Flex. This is rather straight forward, but requires some knowledge of the generated code to get right.
Here we present a source template that does this. The user only has to edit the grammar and scanning rules. Some knowledge of C, Yacc and Flex is assumed.
The code is WTFPL licensed.
The template is written for Berkeley Yacc and the Reflex variant of Flex. It may be made to work with GNU Bison and (formerly SourceForge) Flex (now on GitHub), possibly with a few changes.
Table of Contents
Using the Template
In the file commandline.l we start to edit the scanner rules. For our example we make do with
%%
// Here we put regular old scanning rules.
[a-z]+ { commandlinelval = commandlinetext; return WORD; }
%%
The only thing different here is that our customary yylval and yytext variables have changed names. The WORD token is defined in commandline.y.
Then in commandline.y we edit grammar rules as usual. We start with a list of tokens.
// Here we put regular old token declarations. %token WORD SPACE
and then write our grammar
%%
// Here we put regular old grammar rules.
command: /* empty */
| words
;
words: word
| words word
;
word: WORD { printf( "\"%s\"\n", $1 ); }
;
%%
Here we just print out the words returned by the scanner, one per line. We are using the fact that the lexer starts a new lexeme on calls to yywrap(). This means we do not have to insert any separator characters between the command line arguments we are parsing.
The provided makefile builds the example with the -p prefix parameter to yacc, which changes the symbol prefix from yy and the -P prefix parameter to reflex to do the same. This makes the template usable as-is with projects that use yacc & flex already.
% make yacc -bcommandline -pcommandline -di commandline.y reflex -Pcommandline commandline.l cc -o commandline commandline.tab.c lex.commandline.c
Now we can run the example.
% ./commandline this is a simple example "this" "is" "a" "simple" "example"
Understanding the Template
We use the technique presented previously to pass parameters to yacc and flex [link is to an archived copy] to feed argc and argv to our yywrap() function.
In commandlin.h we declare the argument structure.
// The argument structure we pass to yywrap().
struct arguments
{
int argc, // The total number of arguments passed to main().
arg; // The argument we are actually going to parse.
char **argv; // Pointer to the argument vector itself.
};
In commandline.l we have
int nextargument( struct arguments *args )
{
// Prevent memory leaks. This is safe because yy_current_buffer
// is initialized to zero.
if ( YY_CURRENT_BUFFER )
{
yy_delete_buffer( YY_CURRENT_BUFFER );
}
// If there are no more arguments, return 1 to signal we are done.
if ( args->argc == args->arg )
return 1;
// Notice we increase args->arg here with ++.
commandline_scan_string( args->argv[ args->arg++ ] );
return 0;
}
as the yywrap() function (renamed) which calls yy_scan_string() for each argument passed to main(). yy_scan_string() has been renamed too.
The main() function itself is purely a template which builds a structure holding argc and argv which it then uses to pass on to yywrap() and yyparse().
int main( int argc, char *argv[] )
{
// Initialize the argument structure we pass to yywrap().
struct arguments args;
args.argc = argc;
args.arg = 1; // start at argument 1, not the command name.
args.argv = argv;
if ( argc > 1 )
// This is actually our yywrap() function. We could also have
// used its return value to determine if there is an argument
// to parse.
nextargument( &args );
else
return 1;
// We pass the argument structure to our yyparse(). Notice it's
// been renamed to "commandlineparse."
commandlineparse( (void *) &args );
return 0;
}
Here we are careful to call yywrap() before our first call to yyparse() to initialize the input buffer.
Depending on the application, there may be no reason to change the main() function itself, merely rename it and called from the actual main().
References
- Passing Parameters to Yacc and Flex [archive.org] (Previous blog entry).
- Berkeley Yacc Website
- Reflex Website
Downloads
Downloads of individual files.
Downloads of the complete source archive.
The Case of the Apparent NSS Memory Corruption
This is a story of my encounter with an apparent memory corruption issue in the Netscape Security Services library.
The source I’m discussing can be found on Github.
Usually, when I try to get acquainted with a new API, I start to write simple program, one API call by call, which I compile and run after each step.
Imagine my surprise, when after adding the following function call (the only thing I added)
PK11_FindKeyByAnyCert( certificate, passwd );
I got this memory corruption error.
dblfree(56630,0x7fff73f61300) malloc: *** error for object 0x7fd39250ce70: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug zsh: abort ./dblfree
The above error is taken from my minimal example of the problem, not the actual program I was working on at the time. The only difference is the name of the binary and the hex numbers.
So what is happening here? I didn’t know. And to find out, it’s really important to use the right tool for the job.
So the first thing I did was to instrument my code with the built-in OS X tools, instruments(1). That didn’t tell me much; either because it doesn’t help in this particular instance, or that I just don’t know how to use it.
I will make a note that some people suggested Valgrind. I didn’t go that way because the problem seems to be adequately described with the Clang Address Sanitizer.
Continue reading The Case of the Apparent NSS Memory Corruption
When Dtrace Fails – Spectacularly
So, I’ve been spending some time looking at Dtrace today. At first, I created a proof of concept on OS X, and then went on to try it in production on FreeBSD.
No such luck. After several hours of trying to figure out what the heck was going wrong, I tried the following experiment, on OS X.
% uname -a
Darwin foo 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64
% cat hello.c
#include <stdio.h>
int main(int argc, char *argv[]) {
printf( "Hello\n" );
return 0;
}
% dtrace -n 'pid$target::main:entry{printf("%#p\n",uregs[R_RBP]);}' -c ./hello
dtrace: description 'pid$target::main:entry' matched 1 probe
Hello
dtrace: pid 9224 has exited
CPU ID FUNCTION:NAME
0 67470 main:entry 0x7fff583c1c20
And then again on FreeBSD.
% uname -a
FreeBSD bar 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
% cat hello.c
#include <stdio.h>
int main(int argc, char *argv[]) {
printf( "Hello\n" );
return 0;
}
% dtrace -n 'pid$target::main:entry{printf("%#p\n",uregs[R_RBP]);}' -c ./hello
dtrace: description 'pid$target::main:entry' matched 1 probe
Hello
dtrace: pid 84313 has exited
CPU ID FUNCTION:NAME
2 54008 main:entry 0
As you can see, the printed value of the %rbp register is zero on FreeBSD. In my experiments, trying to read that register always yields zero. Similarly, I do not trust it for other registers.
This seems to be a bug in FreeBSD’s Dtrace. At the time of this writing, I have not tried it on recent Illumos.
CTemplate Emitter for Stream Output
Google’s CTemplate has very customizable output features, yet it does not come with an emitter (the type of class that actually outputs the template with all the variables filled in) for standard streams. Hence there is no default way to output to std::cout.
Or I was unable to find one.
Therefore, here is a very simple emitter for stream output.
class StreamEmitter: public ctemplate::ExpandEmitter
{
public:
StreamEmitter( std::ostream &out ) : sout( out )
{
}
virtual void Emit( char c )
{
sout << c;
}
virtual void Emit( const std::string &s )
{
sout << s;
}
virtual void Emit( const char *s )
{
sout << s;
}
virtual void Emit( const char *s, size_t len )
{
sout.write( s, len );
}
private:
std::ostream &sout;
};
Then it can be used like this.
// Assume pageDict has been initialized and the variables filled in...
StreamEmitter coutEmitter( std::cout );
ctemplate::ExpandTemplate( "template_file", ctemplate::DO_NOT_STRIP, &pageDict, &coutEmitter );
Am I really the only one who wants to emit templates to streams?
Licenese: Three clause BSD (same as CTemplate itself).