shakna-israel / cnoevil

CNoEvil - A Language Extension for C

CNoEvil - A Language Extension for C

---

Deprecation Notice

This has been deprecated, and should be replaced by the largely-compatible approach here.

---

Master:

This is a pet project of mine, abusing the hell out of the C pre-processor, and other C language features, to create a language that is still technically C, but looks and behaves differently, whilst remaining fully compatible with C.

It takes a whole lot of bad ideas and mashes them into an abhorrent monstrosity.

#define EVIL_IO
#include "evil.h"

Main then
  displayln("Hello, World!");
end

A larger example of using CNoEvil is esh, a very basic shell.

---

Usage

CNoEvil is contained into a single C header file, evil.h. Drop that file somewhere in your include path.

You will need a C compiler capable of the C11 standard, and some optional features may require a GNU compiler.

Define which modules you want to use, or not use, and then include it.

#define EVIL_IO
#define EVIL_NO_CONSTANT
#include "evil.h"

Main then
  displayln("It works!");
end

For the full usage, compile and run:

#define EVIL_HELP
#include "evil.h"

Main then
  evil_manual();
end

For individual help, compile and run:

#define EVIL_HELP
#include "evil.h"

Main then
  evil_explain("constant");
end

Where the string is the name of what you wish to look up.

If that still fails you, open an Issue on GitHub, and I'll try and help.

---

Versioning

I plan to have very feature and every bugfix have it's own number increment, so numbers may rapidly increase.

I'm roughly following semantic versioning.

Thus:

MAJOR.FEATURE.BUGFIX

MAJOR will only change with breaking API behaviour, and will be avoided.

FEATURE will bump every time something new is added to the library.

BUGFIX will bump every time we get a new bugfix.

FEATURE and BUGFIX will only ever revert to 0 if MAJOR increments.

So, for example, this kind of version would be possible:

1.256.893

---

License

... You actually want to use this?

Really?

Okay... See LICENSE.md.

cnoevil's Issues

Malloc-check

Malloc-checks are a pattern, so we can simplify it easier.

char** tokens = malloc(bufsize * sizeof(char*));
If !tokens then
    critical("esh - Could not allocate memory for tokenising...");
    exit(1);
end

Maybe:

checked_malloc(tokens, char**, bufsize * sizeof(char*), "Failed to allocate.", true);

(Variable, type, buffer to allocate, error message, do we exit?)

Function pointers

One of the most complicated parts of C's syntax is declaring function pointers.

Can we simplify it?

Function pointer declarations:

int (*builtin_func[]) (char **) = {
  &esh_cd,
  &esh_help,
  &esh_exit
};

Function pointer call:

(*builtin_func[i])(args)

Comment macro

A comment macro would be nice.

So I can do stuff like:

comment(This is a basic comment, it's multiline,
and doesn't give a damn about whitespace.);

/*
  This is a basic comment, it's multiline,
  and doesn't give a damn about whitespace.
*/

Including the comments is important, as they can be available during debugging for some systems.

Clang, _Generic and format specifiers.

clang-3.6 -std=gnu11 -Wall -Werror -Wno-unused -g -I.. io.c -o io

io.c:5:13: error: format specifies type 'int' but the argument has type 'char *'
[-Werror,-Wformat]
displayln("IO test.");

../evil.h:212:52: note: expanded from macro 'displayln'
  #define displayln(x) printf(display_format(x), x); printf("%c", '\n')

This compiles, and runs correctly on GCC 4.9+, and is ISO C11, so far as I can tell.

Not quite sure why Clang 3.6 (supposedly fully C11 compliant), would fall through to an early test-case in a _Generic.

Declarations

Function declarations are needed.

proc automatically opens a function, so we need something else.

Maybe... declare(PROCEDURE_NAME, RETURN_TYPE);

Do-While

Do-While loops kinda suck at the moment.

Do
    display("> ");
    line = esh_read_line();
    args = esh_split_line(line);
    status = esh_exec(args);

    free(line);
    free(args);
  // Huh. CNoEvil probably needs a way to neaten this up.
  end While status);

The end of the loop requires a hanging ); which is just irritating.

Significant Whitespace

This hasn't got anything to do with the project, I just don't know how else to talk to you and I feel that this is the most relevant repo you have. You have mentioned about how significant whitespace should not be used under any circumstances in CNoEvil, but I want to use it for my own evil purposes. Do you happen to know how to make something like this? I could have sworn you said you figured it out in a comment on a gist but I cannot find it anymore.

Clang, GNU and Lambda.

clang-3.6 -std=gnu11 -Wall -Werror -Wno-unused -g -I.. lambda.c -o lambda
lambda.c:5:54: error: function definition is not allowed here
int (*max)(int, int) = lambda (int, (int x, int y) { return x > y ? x : y; });
^
../evil.h:367:49: note: expanded from macro 'lambda'
#define lambda(ret_type, _body) ({ ret_type _ _body ; })
^
lambda.c:5:26: error: use of undeclared identifier ''
int (max)(int, int) = lambda (int, (int x, int y) { return x > y ? x : y; });
^
../evil.h:367:55: note: expanded from macro 'lambda'
#define lambda(ret_type, _body) ({ ret_type _ _body _; })
^
lambda.c:5:9: error: initializing 'int ()(int, int)' with an expression of
incompatible type 'void'
int (*max)(int, int) = lambda (int, (int x, int y) { return x > y ? x : y; });
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.

So we already knew that Clang didn't support expression statements - they're GNU only.

But, if Clang gets told to operate in GNU mode (-std=gnu11), it'll ignore the error pragma telling it that this is for GNU compilers only.

Maybe we need to fence it also with a define check for something Clang only...

evil_explain

evil_explain should cover all the macros in the library.