Linux Programming Hints
argv is often checked within main() to find out what name was used to invoke the program. However, for error reporting mechanisms to work, a variable pointing to argv has to either be global within at least some part of your program or be passed around a lot from function to function and used as an argument to your error handling functions—both of which can get rather messy.
The GNU C library provides two variables, which are automatically initialized before main() is called, which solve this problem. char *program_invocation_name contains an exact copy of the name found in argv, and char *program_invocation_short_name contains a copy with all the leading directory names stripped off. So if program_invocation_name contains /usr/bin/foo, program_invocation_short_name contains foo.
With these two variables, error handling functions become a lot simpler and more generic. It is possible to make clean error handling functions without these pre-provided variables, but it requires that you initialize your error handling functions, probably from main(), during program initialization. If you assume that the GNU C library is available, you can simply access these variables directly, cutting down on the possibility of programmer error.
The GNU C library contains built-in heap consistency checking, meaning that it can check to see if a program has violated some of the rules for accessing dynamically allocated memory. By calling the mcheck() function before any memory allocation functions are called, you can ask that some consistency checks be occasionally made and an error function be called if there are any inconsistencies.
You can also define functions that are called directly before malloc(), realloc(), and free() are called, to check for errors. mcheck() is implemented by using these hooks, but it is still possible for you to use the hooks even if you are using mcheck() because the functions are “chained”—you just need to follow the rules and the example given in the reference manual to get this to work correctly.
An mstats() function is provided, which gets memory allocation statistics including:
The total number of bytes being managed by malloc() (etc.), including memory that has been allocated from the operating system but not allocated to your program by malloc().
The number of bytes actually allocated to your program.
The number of “chunks” that have been allocated from the operating system, but which are not in use.
The number of “chunks” that are actually in use.
The number of free bytes which have been allocated by malloc() from the operating system, but which are not currently allocated to your program.
A dynamic stack allocation facility called obstacks is available, and this can be more efficient for some things than malloc. Obstacks have some limitations, but they are implemented as macros and are very quick for small, repeated allocations. They also have a lower space overhead for each small block than malloc() does.
Obstacks are built on malloc() in much the same way that malloc() is built on the system call brk().
A relocating allocator is also provided. This is a memory allocator which provides blocks of memory which may be moved around at any time behind the scenes, and which are therefore referenced through a “handle” which is updated whenever the memory is moved.
It can be a little more work to program with relocating memory because you have to work with, for example, a char ** instead of a char *, but if your program regularly allocates and de-allocates memory in a more-or-less random way, the relocating allocator can provide significant memory savings.
Because there are no really good functions in the standard C library for reading lines, the GNU C library provides some extra functions which are not completely compatible but which work much better. getline() can safely read a string as long as memory can hold. getdlim() is a generalized version of getline(), which gets text until some delimiting character is reached again, without arbitrary limits on how long the line can be. In these functions memory is allocated from within the function, instead of the function requiring you to pass it memory. You are required to free this memory when you are done with it.
Safe formatted string I/O is provided by snprintf(), asprintf(), and obstack_printf() the first of these is a version of sprintf() which knows how long a string it has to write into; and the other two dynamically allocate whatever space they need, like getline() and getdlim().
The GNU C library provides functions for customizing printf(). You can define a %q format for the standard printf(), for example, and make it do whatever you want. If you would like to be able to easily print out structures in your application, simply make printf() conversions for them, and pass pointers to structures into printf(). If %q is your generic structure-printing conversion, and struct foo has been designated as structure number 1, you could make it possible to write: printf("%1q\n", &foo); and have the contents of foo printed out for you.
scanf() is compatibly extended so that it can optionally allocate string storage itself, so, for instance, you don't have to have a maximum string size.
It is also possible to do standard I/O on memory, using functions like fmemopen() to get a FILE * which references memory instead of a file. Now all your standard I/O functions can be used to write into memory. It is even possible to define your own types of streams, so you could, for example, write a set of procedures which allow you to use fprintf() to “print” to something via SYSV IPC messages.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide