Non-constant initializers

[Uncle Steve]

Why, yes.

I am totally open to reconsidering this if I am ever exposed to an example
of a bug-free program. And no, I haven't seen one yet. And I'm including
things like "an assembly program which exists only to execute a single
instruction which takes no operands".

Obviously, the existence of a bug-free program would be a matter of
some significance to the computer science community. This might be a
fruitful research topic for a team of committed graduate students...
Surely there would be a paper in it *if* such a thing could be found.

And the people who are doing that are often wrong -- if not on the machine
they started on, on the machine their code goes live on.

There are a few people doing stuff on multi-billion dollar supercomputers
who might not be stupid to do that stuff. Not many. Mostly, it's better
to spend the time on things that will have higher payoffs.

Like.... better algorithms. I with you here on this, Peter.



Regards,

Uncle Steve

 

[Malcolm McLean]

Like.... better algorithms.  I with you here on this, Peter.

But, mainly, better error checking and integration of programs.

Most projects don't fail because the CPU is 50% too slow, or even
because the wrong big O algorithm was chosen, but because the program
doesn't talk properly to other programs, or because it contains a mass
of niggles if not actual bugs.

 

[Uncle Steve]

But, mainly, better error checking and integration of programs.

Most projects don't fail because the CPU is 50% too slow, or even
because the wrong big O algorithm was chosen, but because the program
doesn't talk properly to other programs, or because it contains a mass
of niggles if not actual bugs.

I've got no previous experience with projects that died because of an
inability to fix bugs, or because of some other flaw. I imagine even
corporate culture, in and of itself, might be a determining factor in
the success or failure of a project. And then there's coding
standards and methodologies...

Since I'm the only developer working on my project, I have the freedom
to dictate my arbitrary coding standard, which is comfortable for me
but which might annoy the hell out of someone who does things
differently. Parallel programming (more than one programmer working
on a program at once) is a logistics nightmare for non-trivial cases;
it's easy to see how some projects might never get off the ground.



Regards,

Uncle Steve

 

[Dr Nick]

easy
if a routine can have its input in some range example 1..1000
it is possible to show that for all valid input it return the right
answer; for invalid input it return always error

Not necessarily. And of all the places to make that statement,
comp.lang.c is one of the worst.

Consider a C program that does this but reads or writes one off the end
of an array. It may well work perfectly on testing, and in production
for months, until one day the machine is particularly busy and it gets a
non-zero'd chunk of memory and suddenly returns the wrong result - or
just crashes. I've seen this happen (OK, confession time, I caused it).

 

[Stefan Ram]

Obviously, the existence of a bug-free program would be a matter of
some significance to the computer science community.

How would one know it's bug-free?

Is the following program bug-free (untested)?

#include <stdio.h>
int main( void ){ printf( "Hello world!\n" ); }

 

[Seebs]

How would one know it's bug-free?

It'd be very hard to tell.

Is the following program bug-free (untested)?

#include <stdio.h>
int main( void ){ printf( "Hello world!\n" ); }

In C99, probably. In C89, of course, it falls off the end of a
function with a return type, and its return status is... I think the standard
actually said "undefined" but I think it probably meant unspecified. Of
course, that's not to say it's actually correct. In particular, it turns
out that the terms of a recently-signed sales contract require us to fully
localize all code for .jp customers, and the layout doesn't comply with
the current corporate coding standards. Also, by SHEER COINCIDENCE,
it turns out that the host compiler is translating calls to printf with
no format specifiers into calls to puts, and that an unrelated optimization
for string literals used as function arguments is causing the puts
to generate an extra carriage return under some circumstances, and of
course there's the missing comma in "Hello, world!", and our corporate
style guide requires that exclamation marks be used only for imperatives,
not utterances and interjections.

(Okay, maybe some of this doesn't apply. Some of it might. I wouldn't
approve it if it came to me for code review...)

-s

 

[Keith Thompson]

Is the following program bug-free (untested)?

#include <stdio.h>
int main( void ){ printf( "Hello world!\n" ); }

[snip]
Also, by SHEER COINCIDENCE,
it turns out that the host compiler is translating calls to printf with
no format specifiers into calls to puts, and that an unrelated optimization
for string literals used as function arguments is causing the puts
to generate an extra carriage return under some circumstances,

[snip]

Surely that would be a bug in your implementation, not in the program.

[...]

 

[Ben Pfaff]

Is the following program bug-free (untested)?

#include <stdio.h>
int main( void ){ printf( "Hello world!\n" ); }

It doesn't check for errors writing to stdout.

It isn't internationalized.

 

[Keith Thompson]

It doesn't check for errors writing to stdout.

It isn't internationalized.

Ok, how about this (also untested):

int main(void) { return 0; }

(Note: This program is intended only for conforming hosted
implementations.)

 

[Joel C. Salomon]

How would one know it's bug-free?

Is the following program bug-free (untested)?

#include <stdio.h>
int main( void ){ printf( "Hello world!\n" ); }

Ignores value returned from printf(). What happens if there's a problem
with stdout?

(I don't remember where I saw this, but I read an article some time ago
comparing the error-checking version of "hello world" in several
languages. The simple C++ one, for instance, might throw an unhandled
exception.)

--Joel

 

[Seebs]

Also, by SHEER COINCIDENCE,
it turns out that the host compiler is translating calls to printf with
no format specifiers into calls to puts, and that an unrelated optimization
for string literals used as function arguments is causing the puts
to generate an extra carriage return under some circumstances, [snip]

Surely that would be a bug in your implementation, not in the program.

The user doesn't care whose fault it is; what matters is whether the program
runs correctly.

-s

 

[Eric Sosman]

Ok, how about this (also untested):

int main(void) { return 0; }

(Note: This program is intended only for conforming hosted
implementations.)

This attempted reimplementation of /bin/false fails to
satisfy the requirements.

 

[Stefan Ram]

Ignores value returned from printf(). What happens if there's a problem
with stdout?

#include <stdio.h>
int main( void ){ while( printf( "Hello world!\n" )!= 13 ); }

#include <stdio.h>
int main( void )
{ if( printf( "Hello world!\n" )!= 13 )
fprintf( stderr, "Please repair your stdout!\n" ); }

#include <stdio.h>
#include <stdlib.h>
int main( void )
{ return printf( "Hello world!\n" )== 13 ? EXIT_SUCCESS : EXIT_FAILURE; }

 

[Angel]

This attempted reimplementation of /bin/false fails to
satisfy the requirements.

That is because it is actually a reimplementation of /bin/true. (0 ==
true in Unix world.)

 

[Tim Rentsch]

Where does the documentation say this is allowed by C99? The C99
standard says

All the expressions in an initializer for an object that has static
storage duration shall be constant expressions or string literals.

(Section 6.7.8 paragraph 4)

I think this is the relevant section of the gcc document:

6.23 Non-Constant Initializers
==============================

As in standard C++ and ISO C99, the elements of an aggregate
initializer for an automatic variable are not required to
be constant expressions in GNU C. Here is an example of an
initializer with run-time varying elements:

foo (float f, float g)
{
float beat_freqs[2] = { f-g, f+g };
/* ... */
}

C90 requires constant expression for all initializers. [snip]

What I think you mean is C90 requires constant expressions for
all initializers used for aggregates and unions. C90 allows
initializers for automatic variables of scalar type to be
expressions that aren't constant expressions.

 

[Dr Nick]

#include <stdio.h>
int main( void ){ while( printf( "Hello world!\n" )!= 13 ); }

Doesn't qualify if the requirement is that it is guaranteed to terminate.

#include <stdio.h>
int main( void )
{ if( printf( "Hello world!\n" )!= 13 )
fprintf( stderr, "Please repair your stdout!\n" ); }

And if stderr is just as faulty?

#include <stdio.h>
#include <stdlib.h>
int main( void )
{ return printf( "Hello world!\n" )== 13 ? EXIT_SUCCESS : EXIT_FAILURE; }

I think this is getting closer.

 

[Keith Thompson]

Also, by SHEER COINCIDENCE,
it turns out that the host compiler is translating calls to printf with
no format specifiers into calls to puts, and that an unrelated optimization
for string literals used as function arguments is causing the puts
to generate an extra carriage return under some circumstances, [snip]

Surely that would be a bug in your implementation, not in the program.

The user doesn't care whose fault it is; what matters is whether the program
runs correctly.

True, but irrelevant to the issue of "bug-free C code". You might as
well cite an example where the program didn't work because the monitor
wasn't powered on.

 

[Keith Thompson]

That is because it is actually a reimplementation of /bin/true. (0 ==
true in Unix world.)

I'm sure beyond reasonable doubt that Eric knows that.

He raises an excellent point: we can't judge whether a program is
bug-free without knowing what requirements it's intended to satisfy.

So how about this implementation of IEFBR14 (intended only for
conforming hosted C implementations):

int main(void) { return 0; }

 

[Keith Thompson]

C90 requires constant expression for all initializers. [snip]

What I think you mean is C90 requires constant expressions for
all initializers used for aggregates and unions. C90 allows
initializers for automatic variables of scalar type to be
expressions that aren't constant expressions.

Actually I *meant* what I wrote; I was just wrong (I forgot about
non-constant initializers for automatic scalars). Thanks for the
correction.

 

[Seebs]

True, but irrelevant to the issue of "bug-free C code". You might as
well cite an example where the program didn't work because the monitor
wasn't powered on.

I'm not sure about that. I think there's a sort of realm-of-responsibility
you face with code, and in general, I figure you're responsible up to the
edge of the software line when writing code. Maybe even some kinds of
hardware errata.

Consider the famous pentium F00F bug. I think people would generally agree
that a kernel which didn't protect against it was "buggy".

-s