Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


Softpanorama C bulletin, 2003

[Aug 12  2003] Simon hates software

 From: Simon Cozens
Date: 12:36 on 12 Aug 2003
Subject: G"C"C

Arthur Bergman:
> it would be fine if it wasn't for the GODAMN ANAL LINKER that AIX uses!

No, it's that gcc is a complete and utter bloody joke. It will compile and link almost anything. It would probably compile Perl without too much modification and wouldn't even emit that many warnings. Look! Look at this!

    *&(int)f = 1;

Is that C? I don't fucking think so. And look at this:

    FILE *
    concat_fopen (char *s1, char *s2, char *mode)
    {
      char str[strlen (s1) + strlen (s2) + 1];
      ...
    }

Yes, that's supposed to be C, not C++, because the things they've done to C++ are almost bloody unspeakable. The words "embrace" and "extend" come to mind. How about this, for instance:

   It is very convenient to have operators which return the "minimum" or the
    "maximum" of two arguments.  In GNU C++ (but not in GNU C), 

    a <? b --  is the minimum, returning the smaller of the numeric values a and b; 
    a >? b --  is the maximum, returning the larger of the numeric values a and b. 

What? What the hell is that about? And you know the worst thing? People actually use these abortions in real code, because obviously, if it compiles on Linux with gcc, it'll compile anywhere. That's why you're having problems linking on AIX - because nobody's even thought about AIX before. We use
autoconf, right, so it must be portable?

Yeah, fucking right. Portable between GNU OSes, I think you'll find.

Part of the reason Parrot 0.0.1 was so slow getting out of the door was because of all these stupid idiots writing GCC "C" and not realizing how completely fucking broken it was.

Of course, number one stupid idiot was myself, but the point remains, dammit!
 

[Sep 24.  2003] Cyclone

A Safe Dialect of C
Download! Cyclone Version 0.6 (3.0MB, 24 Sep 2003)

Read! the documentation (download)

Join! Cyclone mailing lists or send comments

Cyclone is mirrored at Cornell and AT&T Labs Research.

Synopsis

Cyclone is a programming language based on C that is safe, meaning that it rules out programs that have buffer overflows, dangling pointers, format string attacks, and so on. High-level, type-safe languages, such as Java, Scheme, or ML also provide safety, but they don't give the same control over data representations and memory management that C does (witness the fact that the run-time systems for these languages are usually written in C.) Furthermore, porting legacy C code to these languages or interfacing with legacy C libraries is a difficult and error-prone process. The goal of Cyclone is to give programmers the same low-level control and performance of C without sacrificing safety, and to make it easy to port or interface with legacy C code.

Cyclone achieves safety while remaining compatible with C by:

Cyclone also provides modern features for convenient programming:

Software Distribution

The Cyclone compiler and tools, as well as some benchmark programs, are freely available for download.

System Requirements:

Licensing: The files in the distribution come from a variety of sources and so come under a variety of licenses. Please see each file and directory for its licensing terms.

Download Cyclone version 0.6

Download Cyclone documentation

Download Benchmarks version 0.4

 

Papers

Cyclone: A Safe Dialect of C, Trevor Jim, Greg Morrisett, Dan Grossman, Michael Hicks, James Cheney, and Yanling Wang.  USENIX Annual Technical Conference, pages 275--288, Monterey, CA, June 2002.
PS PDF DVI

Region-based Memory Management in Cyclone, Dan Grossman, Greg Morrisett, Trevor Jim, Michael Hicks, Yanling Wang, and James Cheney.  ACM Conference on Programming Language Design and Implementation, pages 282--293, Berlin, Germany, June, 2002.
PS PDF DVI 
Cornell CS Technical Report TR2001-1856 contains the full definition and safety proof for the formal language sketched in the paper: PS PDF DVI 

Safe and Flexible Memory Management in Cyclone, Mike Hicks, Greg Morrisett, Dan Grossman, and Trevor Jim.  University of Maryland Technical Report CS-TR-4514, July 2003. 
This paper describes how we have integrated unique pointers, reference counted objects, and dynamic regions into the language.

More information

Mailing Lists: We have set up three mailing lists for public use:

Go to http://lists.cs.cornell.edu/mailman/listinfo/ to subscribe/unsubscribe, or click the links below to send a message (only list members may submit to Cyclone-l).

Credits: Cyclone is a joint project of AT&T Labs Research and Greg Morrisett's group at Cornell University; see the Acknowledgments section of the documentation for details. Here are some links to personal web pages:

Trevor Jim
Greg Morrisett
Dan Grossman
James Cheney
Mike Hicks
Mathieu Baudet
Matthew Harris
Yanling Wang

C Elements of Style C Elements of Style was published by M&T books in 1992. An abbrivated copy of the book is presented here. This book covers only the C language and is a bit out dated. However it still contains a lot of good advice. Note: The HTML conversion is not perfect. If you want things nicely formatted, get the PDF version.

Table of Contents HTML Format PDF Format
Chapter 1: Style and Program Organization HTML Format PDF Format
Chapter 2: File Basics, Comments, and Program Headings HTML Format PDF Format
Chapter 3: Variable Names HTML Format PDF Format
Chapter 4: Statement Formatting HTML Format PDF Format
Chapter 5: Statement Details HTML Format PDF Format
Chapter 6: Preprocessor HTML Format PDF Format
Chapter 7: Directory Organization and Makefile Style HTML Format PDF Format
Chapter 8: User-Friendly Programming HTML Format PDF Format
Chapter 9: Rules HTML Format PDF Format

Open Watcom - Portable Compilers and Tools

Open Watcom is a joint effort between SciTech Software Inc, Sybase®, and the Open Source development community to maintain and enhance the Sybase Watcom C/C++ and Fortran compiler products. Plans for Open Watcom include porting the compiler to the Linux and FreeBSD platforms, as well as updating the compilers to support the latest C and C++ ANSI standards.

The Open Watcom development team has released version 1.1. You can download the source and binaries here.

To keep up with the latest news, participate in the Open Watcom community

Intel® Compiters

icc The New Intel C Compiler for Linux by Jake Jenkins

Table of Contents:
Overview
The Good
The Bad
Optimization Switches
Performance vs. GCC
Caveats

Overview

Recently, Intel released its newest compilers for C/C++ and Fortran77/90 for the Linux platform. Calling them simply C++ and Fortran Compilers 5.0 does a them bit of disservice. These compilers have been long awaited by developers and it seems the wait has been worth it. Most serious developers on the Intel architecture know that while these processors are capable of performance rivaling that of high end workstation CPU's, making the Intel's peak performance available required the purchase of commercial libraries or hours of tedious assembly coding. This is due to the fact that there exists on every Intel processor since the Pentium III, a special feature known as SSE. SSE is really just a marketing term for the Pentium III and later's high powered floating point unit. SSE is actually composed of 8 128bit registers whose sole purpose is to perform floating point arithmetic. As you will see later in the article, utilizing these extra registers to their fullest potential can lead to tremendous performance increases in applications which make heavy use of floating point calculations.

The Good

Fortunately for those of us who use Linux, the compilers can be had for free for non-commercial use. For Windows users in an academic environment, the cost is relatively low as well at under $100 per user.

Links

Intel

A good benchmark repository

MCSR

[SLL] A small page about the Intel C-C++ compiler

Take a look at http://developer.intel.com/software/products/eval/

Note that Linux products have two links:
    30-day Free Evaluation Software (Includes Support) 
    Non-Commercial Unsupported Software 

I wrote a small document months ago (when there was only available beta
releases) about installing the compiler, but now its outdated (the
non-commercial version doesn't require you to mess with the temible flex
license manager :-)

Small Tip for Debian Potato users: choose the  Red Hat 6.2 on IA-32
Processors, do an apt-get install rpm and you should have no problems
installing it

About the GCC efficiency (or lack of it): All I can say is that much has been
discussed about this issue and the conclusión I most often hear is that GCC
strength is not in the efficency of the generated binary (which is not so bad
in some platforms) but its portability (you can find a gcc _everywhere_).
Haven't tested gcc 3.x yet, but seems that a lot of work has been done in
this subject (anyone here has experiences with the 3.x branch?)

About the fortran compiler: haven't used it, but I'm pretty sure it has full
fortran 95 support (as well as other goodies like openMP).

FTR: The intel compilers (at least the C/C++ one) are based on the KAI
compiler set (take a look at www.kai.com)

Regards
Pedro

Best Practices for Programming in C -- a typical style-related recipes for C without any new insights, but still the paper has a reasonably balanced approach to the topic. As always some tips are questionable. I doubt that  declaration of the counter in the loop (for(int i=0; i<100; i++) array[i]=0;) is a portable construct. A lot of C-compilers will reject this.  As one of Linux Today readers noted "...if you copy things verbatim from others, *including comments* etc, it would be nicer to name the original authors, ie (?) Henry Spencer ('Ten commandments for C programmers') and Robert Pike ('Notes on programming in C'). But this certainly doesn't ever happen in code written by IBM-employees, does it?"

On a positive side they note usefulness goto in organizing breaks from inner loops:

Sean Etc. - Subject: Pointer qualifer location... ugh ( Jul 28, 2003, 13:39:28 )
"The pointer qualifier, '*', should be with the variable name rather than with the type."
I've never understood this one, and will never agree with it. The pointer qualifier _is_ part of the type, and _belongs_ with part of the type. The only problem with this is when you declare multiple variables, in C, you need a pointer qualifier per identifier; this is just a big bug in C design, so far as I'm concerned.
If you try writing your software with the * next to the type name, it really does get a lot cleaner looking. The * doesn't mesh with and semi-obfuscate the identifier, it doesn't look the same as a pointer dereference, and the type is much more clearly a pointer.

Good Clean Prototype:
mytype_t* foo (char* string);

Problematic C Declarations:
char* string, not_a_string;

Usual Ugly C Style:
mytype_t *foo (char *string);
char *string, *string2;
string = *other_string;

It does rather irritate me tho that most programmers don't move to the cleaner style untils years after they start coding (when they make the sudden realization that it's a better style), because so many teachers and other coders keep teaching the brain-dead style...
 

horne - Subject: Re: Best practices about C hmm ( Jul 28, 2003, 14:17:31 )

for(i=0 to 100)
array[i]=0

I would write the following instead:
for(int i=0; i<100; i++) array[i]=0;


Actually, to ensure the scope of the variable i is limited to the current construct, the use of curly brackets is recommended.

 for (int i; i<100; i++) { array[i]=0; }

This way the variable named 'i' can be reused within the same function without contamination and as a debugging aid. Nobody writes perfect code the first time do they?
 

Tech News - CNET.com  Torvalds: What, me worry? (an interview with Linux Torvalds)

Are there other open-source software development communities you particularly admire?
If I'd have to pick two, I'd pick KDE and the GCC group. I often end up clashing with the compiler people, because the kernel ends up having rather strict needs, and I hate how much slower GCC has become over the years. But there's no question that they're doing some good stuff.

... ... ...

I was talking to (Red Hat Chief Technology Officer and GCC backer) Michael Tiemann about his view that general-purpose compilers, well written, will incorporate broad optimizations that ultimately will produce superior code to compilers with chip-specific optimizations. But now I'm hearing that Intel's C compiler produces much faster software than GCC. Have you tried the Intel compilers, now that you can compile Linux with them?

I haven't really ever gotten around to using the Intel compilers, but I like the fact that there is competition and a baseline to compare against.

And I personally disagree with Michael about general-purpose compilers. Yes, there should be a lot of shared code, but when it comes down to it, the thing that matters most for modern CPUs is just generating good tight code, and the generic optimizations aren't that interesting. But hey, that's just my personal opinion. I'm not really a huge compiler person; I just don't like how the high-level optimizations in current GCC versions are slowing things down without actually giving much of a boost to generated code for C.

Programming in standard C and C++

Dr. Dobb's Journal Interview with Alex Stepanov

Let's consider now why C is a great language. It is commonly believed that C is a hack which was successful because Unix was written in it. I disagree. Over a long period of time computer architectures evolved, not because of some clever people figuring how to evolve architectures---as a matter of fact, clever people were pushing tagged architectures during that period of time---but because of the demands of different programmers to solve real problems. Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it.

[May. 12, 2003]  ONLamp.com What I Hate About Your Programming Language What I Hate About C

Unix.se - Interview - Dennis Ritchie

C is declining somewhat in usage compared to C++, and maybe Java, but perhaps even more compared to higher-level scripting languages. It's still fairly strong for the basic system-type things.

Do you agree with Rob Pike's thoughts on the (ir)relevance of systems research? (http://cm.bell-labs.com/who/rob/utah2000.ps)

Dennis Ritchie: Pretty much, although Rob was stating his case in a deliberately provocative way. It's true that compared with the scene when Unix started, today the ecological niches are fairly full, and fresh new OS ideas are harder to come by, or at least to propagate.

Any thoughts about the GNU project? How did you first learn about it?

Dennis Ritchie: I can't remember when I first learned about it, but a long time ago. The True-GNU philosophy is more extreme than I care for, but it certainly laid a foundation for the current scene, as well as providing real software. The interesting thing is the way that free-software ideas have begun to influence major existing commercial players. At the same time, much of it seems to have to do with recreating things we or others had already done; it seems rather derivative intellectually; is there a dearth of really new ideas? But still, it's a great satisfaction that so much of it has built on top of a basis we helped to establish.


Copyright © 1996-2007 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. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author 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: February 28, 2008