C programming in 2011

[Duncan Bayne]

Hi All,

Many moons ago I cut C code for a living, primarily while maintaining
a POP3 server that supported a wide range of OSs (Linux, *BSD, HPUX,
VMS ...).

I'm planning to polish the rust off my C skills and learn a bit about
language implementation by coding a simple FORTH in C.

But I'm wondering how (or whether?) have things changed in the C world
since 2000. When I think C, I think ...

1. comp.lang.c
2. ANSI C wherever possible (but C89 as C99 isn't that widely
supported)
3. `gcc -Wall -ansi -pedantic` in lieu of static analysis tools
4. Emacs
5. Ctags
6. Autoconf + make (and see point 2 for VMS, HP-UX etc. goodness)

Can anyone who's been writing in C for the past eleven years let me
know what (if anything ;-) ) has changed over the years?

(In other news, holy crap, I've been doing this for more than a
decade).

 

[Shao Miller]

...When I think C, I think ...

...
2. ANSI C wherever possible (but C89 as C99 isn't that widely
supported)
3. `gcc -Wall -ansi -pedantic` in lieu of static analysis tools
...

Agreed.

 

[Stefan Ram]

1. comp.lang.c

Usenet is dying. (Some people say.) Try Twitter?

(Oh, I see you are not using a real newsgroup client,
but Google Groups, so you already support the Web!)

2. ANSI C wherever possible (but C89 as C99 isn't that widely
supported)

ISO C.

3. `gcc -Wall -ansi -pedantic` in lieu of static analysis tools

-std=c99 -pedantic -Wall -Wno-parentheses -Wconversion
(This reflects my personal choice only.)

4. Emacs

Gesundheit! - Real C programms use vi.
Just kidding.

5. Ctags

valgrind, lint, indent, cweb (cweave/ctangle),
subversion/git, cxref, cflow, gprof, cstyle, cdecl ...

6. Autoconf + make (and see point 2 for VMS, HP-UX etc. goodness)

Can this be used on, say, Microsoft® Windows? (I know that
make is available for Windows. I referred to Autoconf.)

 

[Duncan Bayne]

  Can this be used on, say, Microsoft Windows? (I know that

  make is available for Windows. I referred to Autoconf.)

Only via Cygwin (and then, you'd better bundle shtool). But it works
most everywhere else ... and where it doesn't (e.g. Windows) there's
always hand-crafted Makefiles. At least that's the way I used to do
it back in the day.

 

[Duncan Bayne]

Only via Cygwin (and then, you'd better bundle shtool).  But it works
most everywhere else ... and where it doesn't (e.g. Windows) there's
always hand-crafted Makefiles.  At least that's the way I used to do
it back in the day.

In fact, thinking back, I think the way we did it for the
aforementioned POP3 server was to have a Visual C++ 6.0 solution for
building on Windows, Autoconf for most other OSs, plus maybe custom
Makefiles? I think that most of us used Windows as a dev platform,
some (including me) used Linux, and one chap some sort of BSD.

As you can probably tell, my memory of that project is a little
fuzzy

 

[Shao Miller]

In fact, thinking back, I think the way we did it for the
aforementioned POP3 server was to have a Visual C++ 6.0 solution for
building on Windows, Autoconf for most other OSs, plus maybe custom
Makefiles? I think that most of us used Windows as a dev platform,
some (including me) used Linux, and one chap some sort of BSD.

As you can probably tell, my memory of that project is a little
fuzzy

I seem to recall TinyMUX having a similar strategy. It might bring back
some memories for you, should you choose to indulge.

 

[Angel]

Hi All,

Many moons ago I cut C code for a living, primarily while maintaining
a POP3 server that supported a wide range of OSs (Linux, *BSD, HPUX,
VMS ...).

Oh, what was the name of that server? I'd like to know...

I'm planning to polish the rust off my C skills and learn a bit about
language implementation by coding a simple FORTH in C.

But I'm wondering how (or whether?) have things changed in the C world
since 2000. When I think C, I think ...

I've been trying to shake the rust off of me for some time, last time I
did any real serious programming was back in college about 10 years ago.

1. comp.lang.c

I'm new here myself, joined a few months ago. Seems like a friendly and
helpful group most of the time.

Which reminds me, I should thank everyone who answered my query here.
Making my code more portable didn't only make my program work on Sparc
and PPC, it also made the coding as a whole a heck of a lot easier.

2. ANSI C wherever possible (but C89 as C99 isn't that widely
supported)

I tend to stick to C99 as it has many good features that I missed in old
C. It really is an improvement IMHO.

3. `gcc -Wall -ansi -pedantic` in lieu of static analysis tools

I tend to use 'gcc -std=gnu99 -Wall -Werror' as I mostly develop for
Linux/GNU, but I avoid gcc-specific constructs where I can.

4. Emacs

Vi IMproved for me, but whatever works. The Linux kernel folks seem not
too fond of emacs' default layout for C though, just saying...

5. Ctags

Good stuff. ^^

6. Autoconf + make (and see point 2 for VMS, HP-UX etc. goodness)

I have to figure out autoconf someday...

 

[Chris H]

Usenet is dying. (Some people say.)

Sadly true.

Try Twitter?

Orrible :-(

(Oh, I see you are not using a real newsgroup client,
but Google Groups, so you already support the Web!)


ISO C.

ISO-C95 NOT C99
However ISO C 12 may be an improvement.

No. Use a proper static analyser.

Editor etc is personal preference.

 

[Chris H]

I tend to stick to C99 as it has many good features that I missed in old
C. It really is an improvement IMHO.

Good luck.... most compilers do NOT support C99. Those that *claim* to
only support parts of it.

Most areas of the industry tend to avoid C99 all together.

 

[Duncan Bayne]

Oh, what was the name of that server? I'd like to know...

DPOP.

Vi IMproved for me, but whatever works. The Linux kernel folks seem not
too fond of emacs' default layout for C though, just saying...

The only oddity I've noticed is indenting in loops, like:

while (foo)
{
bar();
}

I have to figure out autoconf someday...

Let me know when you do ;-) I've figured out just enough to do what I
need, & nothing more

 

[James Kuyper]

Good luck.... most compilers do NOT support C99. Those that *claim* to
only support parts of it.

It's true that very few compilers fully support C99, But it's also true
that compilers which support most of the new features of C99 are quite
commonplace nowadays.

 

[Francois Grieu]

Can anyone who's been writing in C for the past eleven years
let me know what (if anything;-) ) has changed over the years?

In my experience, both the robustness and code quality of
mainstream compilers (including but not limited to GCC 4,
MS Visual C, Keil C for ARM) has vastly improved.
You'll still often find ugly bugs [1] with these, but very
rarely in the worse category: "generate wrong code".

You can now expect the most obvious optimizations to be
automatically applied [2][3], and will on occasions be surprised
(e.g. by removal of code that is dead only at second glance).

For many of these compiler, inline, __inline, __forceinline
or whatever it is called works, and when ISO C 90
conformance is not necessary, is better than macros.

One the other hand, compilers for less mainstream embedded
platforms must still be expected to generate code that is
badly suboptimal and often wrong.

Francois Grieu


[1] for example compiling these two lines
#if 1?1?1:1:1
#endif
with MS Visual C gives:
fatal error C1017: invalid integer constant expression



[2] many compilers optimize
for(j=0;j<10;++i)
foo();
into the obvious code for
j=0;
do
foo();
while(++j<10);



[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>8u)
foo();

 

[Francois Grieu]

Can anyone who's been writing in C for the past eleven years
let me know what (if anything;-) ) has changed over the years?

In my experience, both the robustness and code quality of
mainstream compilers (including but not limited to GCC 4,
MS Visual C, Keil C for ARM) has vastly improved.
You'll still often find ugly bugs [1] with these, but very
rarely in the worse category: "generate wrong code".

You can now expect the most obvious optimizations to be
automatically applied [2][3], and will on occasions be surprised
(e.g. by removal of code that is dead only at second glance).

For many of these compiler, inline, __inline, __forceinline
or whatever it is called works, and when ISO C 90
conformance is not necessary, is better than macros.

One the other hand, compilers for less mainstream embedded
platforms must still be expected to generate code that is
badly suboptimal and often wrong.

Francois Grieu


[1] for example compiling these two lines
#if 1?1?1:1:1
#endif
with MS Visual C gives:
fatal error C1017: invalid integer constant expression



[2] many compilers optimize
for(j=0;j<10;++i)
foo();
into the obvious code for
j=0;
do
foo();
while(++j<10);



[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>7u)
foo();
[fix typo; compilers should do optimization]

 

[Branimir Maksimovic]

[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>7u)
foo();

No, it can;t.

 

[Francois Grieu]

[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>7u)
foo();

No, it can't.

Would you please illustrate by an example when that does not stand?
Stick to C99, please.

Francois Grieu


Note: my version of GCC makes VERY good code for

#include <limits.h>
#include <stdio.h>
int main(void)
{
int j;
j=INT_MIN;
for(;
{
if ((j<1 || j>8) != ((unsigned)j-1u>7u))
{
printf("%d\n",j);
return 1;
}
if (j==INT_MAX)
break;
++j;
}
return 0;
}

 

[Nobody]

Can this be used on, say, Microsoft® Windows? (I know that
make is available for Windows. I referred to Autoconf.)

MSys provides bash and standard Unix utilities for Windows.
Regardless of autoconf, you'll probably need MSys if you want to
use Unix Makefiles on Windows. Writing Makefiles which work with either
/bin/sh or cmd.exe is too much work.

Cygwin is overkill if you just need to make a Unix build system work on
Windows. It's only really necessary if you need to make complex Unix
software work on Windows with minimal changes.

 

[Branimir Maksimovic]

[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>7u)
foo();

No, it can't.

Would you please illustrate by an example when that does not stand?

When j is in range [-8 , 0]

Actually: if(j < -8 || j > 8)
can be rewritten as: if((unsigned)j>8)

 

[Willem]

Branimir Maksimovic wrote:
) On Thu, 26 May 2011 17:23:01 +0200
)
)> On 26/05/2011 16:21, Branimir Maksimovic wrote:
)> > On 05/26/2011 04:04 PM, Francois Grieu wrote:
)> >> [3] some compilers know that, when j is an int,
)> >> if (j<1 || j>8)
)> >> foo();
)> >> can be rewritten as
)> >> if ((unsigned)j-1u>7u)
)> >> foo();
)> >
)> > No, it can't.
)>
)> Would you please illustrate by an example when that does not stand?
)
) When j is in range [-8 , 0]
)
) Actually: if(j < -8 || j > 8)
) can be rewritten as: if((unsigned)j>8)

Is this meant to be some kind of joke ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Pierre Habouzit]

On 05/26/2011 04:04 PM, Francois Grieu wrote:
[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>7u)
foo();

No, it can't.

Would you please illustrate by an example when that does not stand?

When j is in range [-8 , 0]

C99 doesn't assure you both are equivalent. I think what Francois tries
to say is that gcc can produce assembly that will do the same as

if ((unsigned)j - 1u > 7u)

and that's indeed what GCC does, since on the architectures GCC targets
with the implementation choices it makes, both are equivalent.

 

[Willem]

Pierre Habouzit wrote:
)> On Thu, 26 May 2011 17:23:01 +0200
)>
)>> On 26/05/2011 16:21, Branimir Maksimovic wrote:
)>> > On 05/26/2011 04:04 PM, Francois Grieu wrote:
)>> >> [3] some compilers know that, when j is an int,
)>> >> if (j<1 || j>8)
)>> >> foo();
)>> >> can be rewritten as
)>> >> if ((unsigned)j-1u>7u)
)>> >> foo();
)>> >
)>> > No, it can't.
)>>
)>> Would you please illustrate by an example when that does not stand?
)>
)> When j is in range [-8 , 0]
)
) C99 doesn't assure you both are equivalent.

Are you sure ? As far as I know, casting a signed integer to unsigned
is defined for negative numbers as being INT_MAX minus that number.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT