Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Softpanorama C bulletin, 2002

[May 16, 2002] TutorialSearch

Packages beginning with letter C

[Apr 19, 2002]C-Scene Issues 1..9 free C/C++ zine. Nine issues are currently avaiable. Quality varies.  Among papers:

[Mar 4, 2002] Computer Stupidities Programming some revealing fragments of C programs ;-)

[Mar 4, 2002] Are You Ready For C99? A brief look at the most dramatic changes to the C programming language made in the C99 standard.  See also Dennis Ritchie's opinion of the C99 standard

A list of features that should[0] have made it into the C99 standard is available on Thomas Wolf's webpage. Listed below are the changes that most developers would notice or care about at first use.

  1. Increased identifier size limits: specifically 63 significant initial characters in an internal identifier or macro name, 31 significant initial characters in an external identifier, and 4095 characters in a logical source line. These values were 31, 6, and 509, respectively, in C89.

    The small identifier size is the reason so many ANSI functions had terse names (strcpy, strstr, strchr, etc) since the standard only guaranteed that the first six characters would be used to uniquely identify the functions.
     
  2. C++ style/line comments: The characters '//' can now be used to delineate a line of commented text, just like in C++.
     
  3. Macros take variable arguments denoted by elipsees: Function-like macros will accept variable arguments denoted by using the ellipsis (...) notation. For replacement, the variable arguments (including the separating commas) are "collected" into one single extra argument that can be referenced as __VA_ARGS__ within the macro's replacement list.
     
  4. Inline functions: The C language now supports the inline keyword which allows functions to be defined as inline, which is a hint to the compiler that invocations of such functions can be replaced with inline code expansions rather than actual function calls.
     
  5. Restricted pointers: The C language now supports the restrict keyword which allows pointers to be defined as restricted, which is a hint to the compiler to disallow two restricted pointers from being aliases to the same object which allows for certain optimizations when dealing with the said pointers.
     
  6. _Bool Macro: There is a _Bool type which is a actually two valued integer type. True is defined as

    #define true (_Bool)1

    while false is defined as

    #define false (_Bool)0

  7. Variable Declarations can appear anywhere in the code block: No longer do variables have to be defined at the top of the code block.

     
  8. Variable length arrays: These are arrays whose size is determined at runtime.

     
  9. Variable declarations in for loops: Variables can now be declared and initialized in for loops just like in C++ and Java.
     
  10. Named initialization of structs: The members of a struct can now be initialized by name such as is done in the code block below

    struct {float x, y, z;} s = { .y = 1.0, .x = 3.5, .z = 12.8};

  11. New long long type: There is a new type called long long which is at least 64 bits and can be both signed or unsigned. The new suffixes "LL" or "ll" (and "ULL" or "ull") are used for constants of the new long long type.
     
  12. Functions must declare a return value: Function return types no longer defaults to int if the function declares no return type.
     
  13. Last member of a struct may be an incomplete array type. : This is to support the "struct hack" which works on most existing C compilers already. A code example of the struct hack is shown on Thomas's site.
     
  14. Addition of _Complex and _Imaginary number types: A boon for programmers doing any sort of advanced math in their programs.
     
  15. Multiple uses of a type qualifier are ignored after the first occurence: If a type qualifier appears several times (either directly or indirectly through typedefs) in a type specification, it's treated as if it appeared only once. E.g.

    const const int x;

    is the same as

    const int x;

[Mar 4, 2002] How to avoid Memory Leakage

Errors and complex systems
Any developer writing server applications, or other programs running continuously for a longer periods of time, knows how frustrating it can be with processes slowly allocating more and more memory until some other program finally crashes 3 days later after running out of memory. Memory leakage is probably one of the most difficult programming problems to solve, because you cannot easily search thousands of lines of code for a complex logical error that might cause a problem when some unlikely event occurs. If your application interacts with other programs as well, you might not even have any source code to search. If you are really unfortunate, a small error in your application could activate a buggy piece of code in some other program, and eventually that other program might crash the entire system after allocating all available memory. How are you supposed to find out what really happened?

Debugging and Testing
Writing computer programs is not a simple matter. Computers can execute millions of instructions in one second, but they still don't know what to do if you tell them to "draw a circle". Fortunately you can easily make any computer draw a circle by combining a number of simpler instructions. By using even more instructions you can make the computer do even more impressive things, like drawing a house or decompressing a live video stream from a mars. The only problem is, the more instructions you add, the more likely you are to make an error. With modern programs consisting of thousands or millions of lines of code, errors are pretty much unavoidable. This wouldn't be a problem at all if there were only syntactic errors, since these are easily detected by the compiler, but there are also logical errors (bugs) that will pass right through your compiler without a single warning. Many errors are not even serious enough to cause any problems on their own, but when you combine a few of these errors, you get to spend hours reading your own code, trying to figure out what it really does. So how can we find the errors without spending to many hours on every line of code? The answer is pretty obvious. We run the program! If there are any bugs, they will probably show up after running the program for a while. Although this is a very efficient strategy, there are some errors that don't affect the user-interface or any other observable part of the program directly. These errors are much harder to find, since it may take hours or even days before they have any effects on the user-interface. To find these errors without spending hours or days on each test-update cycle, we need to keep track of some more abstract properties of the program, like memory and cpu-usage. By monitoring these properties for some time, you will be able to find trends and predict problems long before you actually get an error message.

You can embed JavaScript-script engine in your C applications By David Wall

You may have been pleased to welcome Microsoft's release of the Windows Script Engine (WSE), which was initially part of the Windows NT 4.0 Option Pack and has been available for use on business operating systems since then. The WSE opens certain aspects of Windows to manipulation via the JScript scripting language, which is very much like JavaScript in many ways. The company added a bunch of objects to represent Windows features, as well.

This was cool, but the greater significance (in my humble opinion) is that Microsoft had made a move toward making JavaScript-like languages the norm for application scripting. Rather than have a whole sheaf of application-specific languages, the move promised to make it easier for us to capitalize on our knowledge of JavaScript for all kinds of fun work.

Netscape saw this as good news as well, and has released the JavaScript API as a C library that may be incorporated, via a header file, in any C application you're writing. In other words, they've put out a file -- a DLL on Windows and a shared library for Unix -- that you can compile into your C applications. You can therefore send whole scripts to the JavaScript engine for processing (it, in effect, instantiates a JavaScript parser instance like the one that's running when your browser is operating). The engine supports scripts that are in compliance with ECMA-262, and with Netscape's JavaScript 1.4 specification.

Best of all, Netscape's C Engine for JavaScript requires no licensing fee. Consider it if you need a user-scriptable application.

Netscape's introductory document on the JavaScript C Engine: http://itw.itworld.com/GoNow/a14724a53277a75978418a3

[Dec 28, 2001] Ch -- an embeddable C Interpreter, C Compiler for C-C++ Developers. See also The Ch Language Environment --- A Review of Ch 2.0 at BYTE.com.  I doubt that Ch can replace a scripting language but you mileage may vary.

[Dec 28, 2001] Digital Mars C and C++ Compilers -- contains free C and C++ compilers and free downloads section.

[Aug 30, 2001] Sun plans release of Forte 3

Sun plans a Sept 10 release of version 3 of Forte for Java, an IDE for Java development. Will support C, C++ and Java.

[Aug 22, 2001] OSNews.com - Exploring the Future of Computing  Interview: Rasterman Speaks of Enlightenment .17

4. Is E17 still based on GTK+? If yes, why did you not choose a C++ API where C++ is known to help a lot when it comes to GUI programming?

The Rasterman: It never was based on gtk+. I use gtk for a few development utils because it's there and works. We have a widget set of our own brewing that uses evas - its an example showcase of how evas can be very powerful - even for an entire widget set. As for c++ - i personally am just not comfortable with it. I come from a background of doing assembly programming. For me C is a very high level language and i just don't feel good about C++. Also the C++ compilers and tool sets for linux are much less mature than their C counterparts - meaning more problems to deal with. You also don't NEED C++ to do good GUI coding. It's a matter of style. e17 has a semi-OO setup. You setup event handlers (think of them as classes) and callbacks (methods if you like) in them - it's a very loose comparison - but it works quite well.

"While we generally think of C as the prototype industrial language -- hard-edged, high-performance, and dangerous-- numerous projects have attempted to wrap C in a more amiable package."

"Among the survivors still in production are: CINT, EiC, elastiC, ICI, LPC, Pike."

"Our survey excludes interpreters not generally available for Unix systems (such as QNC and Think C), those with limited interactivity (the UPS C interpreter), and interpreters that are moribund. We found software product catalogs listing C interpreters that have been orphaned for several years, but all the following systems are in active development."

TheLinuxGurus.org: Teach Yourself C for Linux Programming in 21 Days [Book Review](Jul 04, 2000)
LinuxNewbie.org: Introduction to Programming in C/C++ with Vim (Jul 01, 2000)
IBM developerWorks: The wonders of glib - Making C programming easier(Apr 23, 2000)
dotcomma: Control Flow In C - Loops(Mar 26, 2000)
dotcomma: First Steps With C(Mar 26, 2000)
dotcomma.org: Introduction to C++ Classes for C Programmers(Jan 09, 2000)
Freshmeat: Coding Standards: Good Idea or Subtle Evil?(Jan 08, 2000)
An IRC Tutorial on C Programming(Apr 25, 1999)


Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 30, 2013