11–20 of 108 posts
No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
Segfault is a totally safe way to terminate a process on a modern desktop os. Besides - there is no 'correct' way to write software.
never knew svg could be so beneficial. It can literally optimize your image processing requirements.
Earlier quoted context omitted.
If people always wrote software responsibly we'd have a great deal fewer interesting projects on GitHub
Would it really be so hard to do this exact same thing in a memory safe language? Would that stifle the author's creativity in any way?
I got something working in 65 lines [1]
[0] http://norvig.com/lispy.html
[1] https://gist.github.com/jmikkola/b7c6c644dff1c07891c698f0a52...
No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
So why is it fair to label it irresponsible?
No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
"but this is an irresponsible way to write software" Segfault is a totally safe way to terminate a process on a modern desktop os. Besides - there is no 'correct' way to write software.
In any case it's a bad issue and should not be a normal failure mode for a syntax error.
No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
The author isn't responsible if people read it and think it's how they should be writing C, especially when the objective of writing lisp in as little C as possible is communicated. So why is it fair to label it irresponsible?
No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
Below is some of the relevant code in C/C++ from the virtual machine of Emblem (the Lisp dialect I'm using to implement inter alia my visual dataflow language, Full Metal Jacket). To keep things short I haven't included initialization or the garbage collector. cons_op takes the top two stack entries (one on the stack, the other in tos), conses them, and returns it in tos.
-------------------
typedef struct ListStruct {
void *head;
void *tail;
} *List;
static struct ListStruct consTable[NUM_CONSES];
static List freeStore;
#define hd(X) (((List)(X))->head)
#define tl(X) (((List)(X))->tail)
#define NIL (void *)&consTable[0]
#define null(X) ((X) == NIL)
static void **stack;
static void *tos; /* Top of stack register. */
static long sp;
static void cons_op()
{
List x;
if (null(freeStore)) { cons_gc(); }
x = freeStore;
freeStore = (List)tl(freeStore);
hd(x) = stack[sp++];
tl(x) = tos;
tos = x;
}
Alternatively, instead of C you could use a garbage collected language such as Java, C#, or Go, and then not have to worry about memory management.