Official C Challenge ①

Task:  Come up with an extension to the C programming language.  Provide a clear description of the extension, and a code sample that clearly shows what the extension is intended to do.

Prize:  (Winning criteria are not specified.)  The winner will have his extension featured in the C11 language standard.

My entry:  ... Sorry, I think C is perfect in every way already.

>>1
My entry:  ... Sorry, I think C is perfect in every way already.

YOU WIN

Do small cosmetic changes count?

>>3
If you put lipstick on pig its still a pig.

My entry has unfortunately been preempted by Cilk.

My entry: C++

My entry: Pascal

Unary Operators

unary-expression:
   postfix-expression
   ++ unary-expression
   -- unary-expression
   unary-operator cast-expression
   sizeof unary-expression
   sizeof [i]( type-name )
   hax unary-anus-expression

The hax operator haxes its operand, which may be an unary-anus-expression.

inline C++

>>4
But at least it has nicer looking lips!

inline perl:
int main(void)
{ int a = 23, b = 19;
  int c = __perl($, $$, pop + pop)(a, b);
  char *s = __perl($, $$, pop + pop)(a, b);
  printf("%d + %d =\n"
         " int: %d\n"
         " string: %s\n",
         a, b, c, s);
  return 0; }

output:
23 + 19 =
 int: 42
 string: 42

>>11
also,
int main(void)
{ int a = 23, b = 19;
  printf("%d + %d =\n"
         " int: %d\n"
         " string: %s\n",
         a, b,
         __perl($, $$, pop + pop)(a, b),
         __perl($, $$, pop + pop)(a, b));
  return 0; }
produces the same output.

>>5
+1 for cleverness.

Here's a crazy idea I had, but it doesn't need any extensions:

union {
    void* pointer;
    struct {
        unsigned int address : 48;
        unsigned int extra   : 16;
    } details;
};

Hope I got the values in the right order ...

>>14
two words: middle endian.

>>15
Eggs don't have a middle end, or am I missing something?

>>16
http://en.wikipedia.org/wiki/Endianness#Middle-endian

>>16
You're missing the metaphor.

The middle-endian name makes no sense.

>>19
It makes about as much sense as the common US and Europeon date formats.

Omelette-endian.

>>20
The common European format makes sense, it's just not the most convenient way to format dates.

>>20
Europeon date formats
What doesn't make sense about DD/MM/YYYY ?

>>23
It's backwards.

>>22

18-07-2010 16:51:31
          ^ Endianness changes here!

>>25
That's not a date format, that's a datetime format.

My entry:

Meta-C  (That name is probably already taken)

A built-in scripting language that runs, effectively, as a precompile step.  In otherwords


myfile.metac -> script parser -> myfile.c -> normal C compiler -> etc...

The scripting language might be Perl-like or Python-like, I don't know, but it just needs to be something modern with nice regular expression support.

The script delimiters are /@ and @/.

Example of what you could do:

myfile.metac

#include <stdio.h>

int main(int, char**)
{

  /@
    # (Assuming perl is the embedded language)
    my $n = 5;
    foreach my $i (1 .. $n)
    {
  @/
      printf("this line prints /@$n@/ times, this is time number /@$i@/\n");

  /@
    }
  @/

  return 0;
}

The script parser would expand that to

myfile.c

#include <stdio.h>

int main(int, char**)
{
      printf("this line prints 5 times, this is time number 1\n");

  return 0;
}

This is a pretty trivial example but the concept is very powerful.  You implement most of C++ manually in this way, since nearly everything C++ adds to C is just compile-time crap.  But the bonus would be that you would be in control of how things behave, instead of the C++ compiler.

ISO 8601 BITCH

>>27
Fuck.

The correct expansion would be


#include <stdio.h>

int main(int, char**)
{
      printf("this line prints 5 times, this is time number 1\n");
      printf("this line prints 5 times, this is time number 2\n");
      printf("this line prints 5 times, this is time number 3\n");
      printf("this line prints 5 times, this is time number 4\n");
      printf("this line prints 5 times, this is time number 5\n");

  return 0;
}

>>27
You know you can inline C with Perl, right?

>>27
Still doing string substitution in this day and age?
I'd imagine we'd be past that and started doing AST manipulations instead!

>>30
You mean like with a heredoc?  That's a perl file with C in it.  This is a C file with perl in it.  Subtle difference, maybe.  I like this way better and I think this is more readable.  It still looks like C.

>>32
It still looks like C.
From a bird's eye view it looks more like PHP. By the way, it's not a "C file" -- at least not yet. How can you say you like it better when you aren't even aware of the endless alternatives?

You mean like with a heredoc?
I was thinking of Inline::C but there are many many other methods. If you want a solution nearly as bad as yours I'm sure there's something to be found in Acme. There are also proper pre-processor tools that do what you suggest although, again, not as badly as you'd prefer.

i think it would be cool for c to have python variables like lists and dictonarys also indentatin syntax would be nice :)

i think it would be cool for c to have python variables like lists and dictonarys also indentatin syntax would be nice :)

Listen guys, If nobody's interested in my hax operator, then maybe i'll just leave /prog/ and not come back!!!

>>36
Bye.

>>36
Make that TWO!

>>38
THREE now!


_{Actually just two because I am >>36 :'(}

>>33
From a bird's eye view it looks more like PHP.
Yeah, that's actually what gave me the idea.

By the way, it's not a "C file"
Yes it is.  The OP's post was about extensions to the C language.  If this became an extension, then this is what a C file would look like.

There are also proper pre-processor tools that do what you suggest
Really?  Like what?  I'm genuinely interested.

a solution nearly as bad as yours
You're so deep.

>>40
Yes it is.
Okay fine. But it's really no different than making Something very much like Inline::C a C extension in its own right.
Really?  Like what?
I haven't been interested in using Perl with C in about a decade now, so I don't remember the names of things I came across at the time. I could do a google search for you, but I won't.

You're so deep.
Ahem:
From a bird's eye view it looks more like PHP.
Yeah, that's actually what gave me the idea.
I don't think I need to say any more. You're offered the opportunity to extend the language and this is what you come up with. Even C++ shuffled off that nonsense pretty quick.

#include <stdio.h>

int main(void){
  puts(
#include <<ls | sed 's/\\/\\\\/g;s/"/\\"/g;s/^/"/;s/$/\\n"/;'>>
  );
  return 0; }

>>41
Even C++ shuffled off that nonsense pretty quick.
Not really.  Look at templates.  They're just a dumb compile-time expansion that could be fully handled with an inline script like this.  Then, if there's something about the way templates work that you don't like, you don't need to wait 40 years for C++4x to fix it.  That's what I meant when I originally said
You could implement most of C++ manually in this way, since nearly everything C++ adds to C is just compile-time crap.

>>43
You can't implement the whole of it that way any more. With all the missteps in C++, at least Bjarne had the presence of mind to create a distinct language of it. It's a shame he was too late in making that decision.

I can't help but notice that you jump back and forth between an extension to the language and something explicitly separate whenever it suits you. I don't mind because I don't care, but FYI: you're an idiot.

int counter(int v){
    int inner(int c){
        return v+=c;
    }
   
    return inner;
}

>>44
any more

Since Sepplesix, you mean?

>>45
Well, I LOL'd.

#define /regexp/ /replacement/
real varargs thats are actually built-in and useable like JavaScript args object.
builtin typeof/sizeof for pointers,objects and arrays with real size of allocated memory. Not the joke that is current C sizeof.

ability to work with raw pointers with casts.

sorry meant WITHOTU casts.
A C extension which completely eliminates casts will be really good.
like -fauto-casts
>>48
Yeah, varargs is shitty.

>>48

1. dear lord no just no
2. who cares
3. I think you are confused about the purpose of "sizeof" it is for determining the size of types not objects (yes C has objects I read the standard and I know the definition of "object" in C) and you can write your own goddamn malloc with this feature if you need it to hold your hand this badly... if you think for just a couple minutes about this request you'll realize it's bull because if you don't know how big your object is based on its type then you need to go back to Java or Python or something because systems programming really isn't your thing you know


int a[10], *p = NULL;
sizeof(a); // 40 -- what do *you* think it should be?
sizeof(p); // 4 on 32bit OF COURSE because you're asking for size of a pointer
sizeof(*p); // 4 because you're asking for the size of an int

the above is quite sane and natural and if you're confused about array and sizeof you're really confused about types, go learn about array "decay" because nobody ever really wanted to pass arrays by value so they turn into pointers... if you need sizeof to work you can make the pointer explicit like this:


void func1(int a[1000])
{
    sizeof(a); // 4 on 32bit because a is a POINTER not an array
    // do you honestly think 4k is reasonable for function args? NO
    // that's why arrays are pass by reference and
    // effrything else is pass by value just remember that one bit and you'll be fine
}
void func2(int (*a)[1000])
{
    sizeof(*a); // 4000, duh
}

and if you really want to pass arrays by value then you put them in a struct which is fine too

>>50

that's what void is for, maybe you are just wishing for pointer arithmetic with void pointers which would be nice but that's not what you asked for

it's a damn good thing incompatible pointer assignments (EXCEPT to/from "void *", of course) generate errors because we C programmers crash enough as it is and if they didn't generate errors you'd get crap like this:


fprintf("welcome mister %s\n", luser_name);

in your magical C this would compile fine but you know in my world a "char *" is nothing at all like a "FILE *" (do you know how goddamn often I make this mistake too? compilers are HELPING by catching errors jeez)

and to all the people asking for better macros you know you could just write your own preprocessor that's fine you don't need to mess with mine... you've probably got M4 on your system and Perl and you could probably whip up some real ugly shit to generate C code that looks like it was made by satan's own enterprise coding time

>you don't know how big your object is based on its type
Not everyone has telepathy, or knows the source for foreign/future/closed code which will use the sizeof() or "guess".
You've never written portable, scalable code?

>>52

listen if you need to know the size of a buffer you do it like this


struct buffer {
    size_t size;
    unsigned char *ptr;
};

if you need to know the size of a struct you do this


sizeof(struct sumthin);

if you want to allocate an array it's easy


struct whatever *p = malloc(sizeof(*p) * n);

what exactly are you having problems with... don't know what foreign/future/closed code has to do with anything because if it's closed then you don't NEED to know how much memory something uses because it's not like you can go poking around inside

as for your sentence structure I have a hard time parsing that first sentence it's not like I'm exactly the model of eloquence but I'm just not sure what problem you're having with your programs that you need to figure out the size of an opaque region of memory... besides, you can write your own malloc and add this feature it's not that hard but it will only let you query the size of heap objects not stack objects, obviously

and the ad hominem attacks are a bit puerile, even for these backwaters of the internet... I don't know what code you write so don't go telling me I don't write portable or scalable code for all you know I'm a respectable programmer who just likes to go trolling from time to time hey it could happen

>>51
jeez
Christian C programmer spotted.

>>54
He didn't capitalize ``Lord''.

3/10

JEWS

>>55
He's a modern Christian.

>>53
Holy shit dude, you're like some kind of Bizarro-FV.

Here's as far as I got, I couldn't get the mprotect call working though... I think I need to align it to the page size, and the code I copied didn't work ;_;

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stddef.h>
#include <sys/mman.h>
#include <errno.h>
#include <unistd.h>

typedef int (*goo_ptr)(int);

static int goo(int n, int i) {
    return n + i;
}

/* This one is copied and replaced. */
static int goo_wrapper(int i)
{
    const int n = 0xdeadbeef;
    return goo(n, i);
}

static goo_ptr foo(int n) {
    const int deadbeef = 0xdeadbeef;
    ptrdiff_t size = (void*)foo - (void*)goo_wrapper;
    void* function = malloc(size);
    memcpy(function, goo_wrapper, size);

    void* deadbeef_p = memmem((const void*)function, size, (const void*)&deadbeef, sizeof(int));
    memcpy(deadbeef_p, &n, sizeof(int));

    /* mprotect HEEEEEEEEEEEEEEEEEELP */
    return (goo_ptr)function;
}

int main(int argc, char* argv[]) {
    int n = 1;
    int i = 2;
    goo_ptr goop = foo(n);
    int r = goop(i);
    printf("%d\n", r);
    return 0;
}

>>59
Did you meant to post this in http://dis.4chan.org/read/prog/1279321077/ ?

>>60
Yeah ... what the hell.

>>58
He's probably the original FV.

My entry: dynamic typing

>>63
I'd prefer type inference myself.

>>64
Write a Haskell->C compiler and you get type inference for free.

>>65
ghc -fvia-C

>>65
Installed Size : 665588.00 K

No.

>>65
Yeah and you get forced garbage collection for free too!

Idiot.

>>43
Not really.  Look at templates.  They're just a dumb compile-time expansion that could be fully handled with an inline script like this.
No, they cannot. The most important thing templates give you that can't be done by a script is implicit, automatic instantiation.

Take for instance a simple example, template <T> min(T a, T b) {return a < b ? a : b;}. Once defined, you can call it with ints, floats, Foos, Bars, etc. without ever having to invoke a code generator. It instantiates each version automatically.

By comparison, with a 'dumb code generation script' like you suggest, you need to call your script for each type you'd like to use the function with. Moreover, you have to take care to do it only once for each type (per file at least with a C++ linker), otherwise you will get duplicate function definitions. There is no way to do it automatically without a language extension.

This might seem trivial but it's actually a pretty critical part of parametric polymorphism.

If I could add one language extension to C, it would be to compile a whole project at once instead of one file at a time, and not have to declare functions above where they are called.

Then you wouldn't need any header files. All identifiers are unique in C, so as long as the compiler can find it somewhere in your project, you never need to declare it. You don't need any kind of module system, any import declarations, nothing; as long as the compiler can see a function, you can call it.

And yes, this can be done incrementally. The compiler can just track dependencies, only recompiling those functions that change or that depend on a struct that has changed, and use incremental linking.

>>70 is a pythonista

>>70
gcc void.c

>>70
That sounds more like a compiler extension than a language extension.

All identifiers are unique in C, so as long as the compiler can find it somewhere in your project, you never need to declare it.
Hands up if you see the problem with that

>>71
Python's module system is bad. It is extremely order-dependent, and it's easy to create circular dependencies where code just breaks without any logical warnings. You get into a situation where you can't see classes from a file you imported because it imports another file that imports you, and it depends which one is imported first from main... I don't like it at all. The module system is perfectly logical from a language implementer's standpoint, but it is not practical. If you've had to debug cyclic imports, you'd agree.

http://stackoverflow.com/questions/744373/python-cyclic-imports

What I'm suggesting for C would be completely order-independent. Things like macros in headers would still need to be #included traditionally to be used.

>>73
Well, the language specifies that a function needs to be declared before it can be called. The language extension I'm suggesting would be to change the spec so that a function only needs to be declared somewhere in the same translation unit (not necessarily above where it is called). Then you could get rid of header files entirely for whole-program compilation, and I would expect that compiler developers would add incremental whole-program compilation soon afterward.

This change would of course be entirely backwards-compatible, and you would still support header files for dynamic libraries, macros, and old code.

>>75
I know it's bad, and so is your solution.

>>1
How about a new _Alias keyword, so you can do type-punning in a portable way? Union type-punning is limited and still technically a violation of the spec...

>>73
Language extensions ⊂ compiler extensions

>>77
How about reading Defect Report #283?