Lint gives me a warning at the malloc in that first loop:
warning: improper pointer/integer combination: op "="
Here's the program...it has quite a few runtime bugs, but the main compiler problem is at that malloc line. Please help!
#include <assert.h>
#include <stdio.h>
typedef struct node *node_ref;
struct node {
char *word;
node_ref link;
};
int main (int argc, char **argv) {
node_ref head = NULL;
node_ref p;
int count;
for (count = 0; count < 5; ++count) {
node_ref node = malloc (sizeof (struct node));
assert (node != NULL);
node->word = argv[count];
node->link = head;
head = node; }
for (p = head; p->link != NULL; p = p->link) {
printf ("%p->{%s, %p}\n", p, p->word, p->link); }
return 0;
}
Do your own homework.
Don't use Lint and tools as such.
Your code is valid.
>>1
Disregard that, you are using malloc() but you have not included <stdlib.h>
The compiler (in our case, Lint actually) assumes malloc returns int instead of void *.
read mallocs man page (man 3 maloc)
Before you run lint, try building with warnings enabled. Lint works way, way better as a supplementary tool once you've weeded out most or all of the warnings from your compiler.
And anyway, a real implementation of lint for C would immediately say "Warning: source code is in C. Choose a cleaner language. To disable this warning, #define THIS_IS_A_COMPILER_AND_THUS_MAKES_SENSE_TO_WRITE_IN_C in your code."
>>6 why would you write a compiler in C?
>>8
>>6 said nothing about writing a C compiler in C, but was either referring to generated code, or to writing a compiler for some unspecified language in C. I was challenging on the latter.
WRT PCC: it is a toy and a joke. In order to get decent performance, your C code needs to have knowledge of the hardware you're running the output on. Some of those operations occur very frequently, and an optimizing compiler can do a very good job refactoring those things in slightly different ways for different targets.
Optimizing compilers are very hard to write in C. Stackless python was written in a preprocessed pigin C (called lightweight-C++), and pypy is written in python. GCC and ZetaC both use LISP to model the optimizations. Perl6 is being written in Perl and in GHC.
I can't believe people still care about optimisation when the cost of a faster CPU is so low.
>>10
What, do you work for Intel or something?
People expect something like this:
while (*s++) { *d++ = *s++; }to be automatically unrolled for them in a processor-specific way; some systems are faster doing it with machine-words- some have a way to do a bitwise and on four different masks at the same time (or very quickly). The naive unrolling (even with duff's device) is always slower than GCC's intelligent target-specific unrolling.
And yet, compilers like pcc encourage manual unrolling of loops because they don't do any processor-specific optimizations. pcc will simply make OpenBSD even slower, and harder to read.
That joke needs some work. Intel wrote what is arguably the best optimizing compiler out there, at least for x86.
x86 is a dying platform. Finally.
amd64 (aka x86_64 for Intel suckups) is the new x86 and everybody knows it.
>>13 True, and I thought about that after I posted it.
Nevertheless Intel's compiler optimization has no bearing on how well the code itself is optimized. In other words, even if you're not doing crazy Duff's device unrolling and asm blocks, you still have to be cognizant of how the compiler works and understand how to best write the code in order to take full advantage of the compiler's optimization strategies.
Unfortunately you can rarely guarantee that someone else with their hands on your code is going to use the exact same compiler.
Yeah that sounds like a nice and social to code.
#ifndef __INTEL_COMPILER
#error "Use the compiler I tell you to, fool."
#endif
Perhaps a better idea would be to write portable code in the first place. Plus you know what they say, make the code WORK first. If there is actually a major performance issue, THEN optimise.
Loop unrolling is generally not faster on modern CPUs. for loops are perfectly predicted on newer x86 so all you're doing is wasting I-cache space.
(also, most other things that introduce weird control flow/branching out of the cache/bad branch predicts are also bad, and this probably includes Duff's device)