Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Official C Challenge ①

Name: Anonymous 2010-07-18 12:23

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.

Name: Anonymous 2010-07-18 23:29

>>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.

Name: Anonymous 2010-07-18 23:32

#include <stdio.h>

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

Name: Anonymous 2010-07-19 0:05

>>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.

Name: Anonymous 2010-07-19 0:22

>>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.

Name: Anonymous 2010-07-19 2:21

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

Name: Anonymous 2010-07-19 2:39

>>44
any more

Since Sepplesix, you mean?

Name: Anonymous 2010-07-19 4:43

>>45
Well, I LOL'd.

Name: Anonymous 2010-07-19 7:06

#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.

Name: Anonymous 2010-07-19 7:20

ability to work with raw pointers with casts.

Name: Anonymous 2010-07-19 7:21

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

Name: Anonymous 2010-07-19 8:58

>>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

Name: Anonymous 2010-07-19 9:45

>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?

Name: Anonymous 2010-07-19 10:09

>>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

Name: Anonymous 2010-07-19 11:59

>>51
jeez
Christian C programmer spotted.

Name: Anonymous 2010-07-19 12:26

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

3/10

Name: VIPPER 2010-07-19 14:13

JEWS

Name: Anonymous 2010-07-19 14:23

>>55
He's a modern Christian.

Name: Anonymous 2010-07-19 14:51

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

Name: Anonymous 2010-07-19 14:54

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;
}

Name: Anonymous 2010-07-19 16:20

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

Name: Anonymous 2010-07-19 16:43

>>60
Yeah ... what the hell.

Name: Anonymous 2010-07-19 20:00

>>58
He's probably the original FV.

Name: Anonymous 2010-08-30 17:07

My entry: dynamic typing

Name: Anonymous 2010-08-31 5:52

>>63
I'd prefer type inference myself.

Name: Anonymous 2010-08-31 9:24

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

Name: Anonymous 2010-08-31 10:36

>>65
ghc -fvia-C

Name: Anonymous 2010-08-31 10:50

>>65
Installed Size : 665588.00 K

No.

Name: Anonymous 2010-08-31 11:42

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

Idiot.

Name: Anonymous 2010-08-31 11:47

>>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.

Name: Anonymous 2010-08-31 11:53

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.

Name: Anonymous 2010-08-31 12:05

>>70 is a pythonista

Name: Anonymous 2010-08-31 12:07

>>70
gcc void.c

Name: Anonymous 2010-08-31 12:09

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

Name: Anonymous 2010-08-31 12:24

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

Name: 70 2010-08-31 12:25

>>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.

Name: Anonymous 2010-08-31 12:51

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

Name: Anonymous 2010-08-31 22:10

>>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...

Name: Anonymous 2010-09-01 0:40

>>73
Language extensions ⊂ compiler extensions

Name: Anonymous 2010-09-01 4:40

>>77
How about reading Defect Report #283?

Name: ​​​​​​​​​​ 2010-09-08 22:01


Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List