>take c
>remove null pointers, all pointers should point during declaration to something valid that can be dereferenced, you just fixed all the segmentation faults
>extend struct definition with a concept of "nil" values that can be dereferenced without errors and are used in the same place where null pointers were used
>remove the implicit conversion of arrays to pointers that point to the 0-index of the array and lose all size information, retain array size information and all array information when passed to functions
>overload the concept of pointers with the concept of "fat" pointers that retain size information and perform automatic bound checking during pointer arithmetic (think of it like what malloc and free already do when they know the size of the heap memory block the pointer points to but now it's a language feature), you just solved all the nasty pointer arithmetic bugs
>drop the c preprocessor, maybe it made sense in the 70s, it doesn't make sense now, it's a relic of the past
>instead allow marked c blocks and functions to run during compile time (you can use a system similar to holyc) and allow regular c code to take the place of preprocessor, giving the full expressive power of the c (+ our enhancements) during the preprocessing step
>you just gave every programmer the ability to extend the language and the syntax with powerful ideas and abstractions like raii, smart pointers and possibly even more high level things like asyncronous programming, function decorators and more without any new syntax and without the ugliness and bloat of the c++ templating system
Congratulations, you just created the perfect language and you btfo forever c++ and rust.
c is already perfect
frick off troon
>segmentation fault
>buffer overflows
It isn't
do you even know what segmentation fault is moron? it has nothing to do with C
you say we should replace segfaults and null pointers with something, that can be dereferenced.
okay, but just because you can dereference something doesn't make that value valid. you still need to check if some value == invalid.
at that point, you might as well check if pointer == NULL. and i take hard segfault crashes over subtle value error anytime
sure, if you want to make a new language like that, go ahead
but don't touch C with shit like that
shut up Black folk
null pointers, all pointers should point during declaration to something valid that can be dereferenced, you just fixed all the segmentation faults
struct x
{
chat frickyou[1000000];
};
x* y;
What is y pointing at? Where in memory is this 1 MB of dummy data stored?
It's not something that can't be fixed with the concept of nil values and some small updates in malloc and free to take advantage of the new features. But obviously it needs some more implementation and design.
Programming and logic errors can always occur, that's not what these changes are to prevent. It's to prevent undefined behavior and having the compiler accept code that doesn't make sense as valid code. Null pointer dereferencing doesn't offer any practical benefit, Tony Hoare admitted that null pointers were his 1 billion dollar mistake. Let the programmer derereference the nil value like any other value then handle it in the business logic.
#include <stdio.h>
int main()
{
int *p = NULL;
int x = *p;
printf("%dn", x);
}
This compiles without any warning and gives Segmentation fault when run. Give me one good reason that is a good behaviour.
>remove the implicit conversion of arrays to pointers that point to the 0-index of the array and lose all size information, retain array size information and all array information when passed to functions
>overload the concept of pointers with the concept of "fat" pointers that retain size information and perform automatic bound checking during pointer arithmetic (think of it like what malloc and free already do when they know the size of the heap memory block the pointer points to but now it's a language feature), you just solved all the nasty pointer arithmetic bugs
Forgot to mention that this would also remove the null terminated strings since now character strings become valid types that have well defined bounds that are retained when passed to functions
that is valid C code. you can dereference a NULL pointer in the kernel without any issues.
>that is valid C code. you can dereference a NULL pointer in the kernel without any issues.
What do you gain by derefercing a pointer to int that points to something that is not a valid integer value, not even a valid memory location?
In my C extension this would be the first error
ERROR: NULL not defined
Then the code would be modifed to
int *p;
And this error would occur
ERROR: unitialized pointer declaration: int *p;
At this point the programmer would be enforced to point p to a valid int value during declaration. In fact I would go as far to prevent all uninitialized variable definition and remove the undefined behaviour around variable initializations.
>that points to something that is not a valid
who says that it is not valid? you can have valid data at physical address 0x0.
Or you want to ignore address 0? My university professor did that, when he made c++ have 1 based arrays, by just ignoring the 0th element.
Dereferencing a null pointer is undefined behaviour, as specified by the C standard.
>ESL
For example this code
#include <stdio.h>
void f(char arr[])
{
size_t arr_len = sizeof(arr) / sizeof(char);
printf("%lun", arr_len);
}
int main()
{
char arr[10];
size_t arr_len = sizeof(arr) / sizeof(char);
printf("%lun", arr_len);
f(arr);
}
would print
10
10
because in this version of C array size would be retained when passed to function. Obviously some small tweaks will be needed to explicitly define that arr parameter in f is an array of any size
You just got rid of null terminated strings and simplified and removed all the security risks around string.h
have you trooned already or is this just part of the process?
if your segments are big enough gcc will put this in data so it does not have to push millions of times
else you segfault lol
>emove null pointers, all pointers should point during declaration to something valid that can be dereferenced, you just fixed all the segmentation faults
you cant really do that without adding to runtime one way or another.
stopped reading there btw, youre completely missing the point of c
what can be done, however is to build a program that will follow the lifetimes of variables and their interactions as a tool to map, refactor and debug code.
just with that conceptually simple tool you remove a good portion of possible errors. while making refactoring a lot easier.
all you have to do is map the types, declarations, initializations and then watch if all interactions are between same types.
youre basically traversing a graph. boom.
you put it on display with an intuitive gui. even 3D representations, why the fricknot
you got yourself a tool that will turn anyone into a 10x'er
and now you can now easily implement garbage collection
and human readable 0-cost generics and other self generating shenanigans
i will write this bc it would increase my output
graphical interface based on sdl2 and all
>i will write this bc it would increase my output
>graphical interface based on sdl2 and all
Sounds like an awesome idea anon. Please post a link to your repository and keep us updated. Looking forward to it.
oof, i dont use git rn
and i am in the middle of something serious thats still gonna take quite a while
but you can be sure once i get the ball rolling i will let you know
OR you can write the thing yourself.
thats the idea behind sharing the idea^^
i am surprized there isnt already such a thing
conceptually it isnt something complicated. it doesnt even sound like something very long to write tbh
aparser that can identify a function token and declaration tokens
derive variable names from declarations, keep track if theyre intitialised, if with another var, check in register (if you start with the header files and do emin order, you should get all variables if you follow the declaration rule. as in: parse documents in order of includes-> find declarations, with each declaration check against ledger, if not present, create
if finds variable token, check in ledger.
if not found->is not a valid C program
imean... you start from there, the algos really dont seem like something complicated.
the """hard""" part might be the parsing and representing the relations between variables. which is gonna be just a bunch of pointers in a multi-dimensionally linked list.
and since the = operator is directional, so is the relation between all variables so checking for intialization is trivial.
lol. thats it. the core of the program is less than 2000 chars in high level pseudocode.
imlegit surprized nobody has done something like that until now
I agree, but that is a type of idea that open sores aren't allowed to have.
care to elaborate on that?
>if your variables are as easy to inspect as clicking on em, it would help alot in maintaining code correctness
That's just a debugger, there are already UIs for that.
>keep track if theyre intitialised
Base compiler warnings will already give you that. For more complex cases, sanitizers already do everything you mentioned.
>That's just a debugger, there are already UIs for that.
ah. still gonna write mine. like i wrote, its not a big project, and given i write it from scratch i can do whatever i please with it. generics are an option. maybe garbage collection and such. idk yet,but ill certainly explore the capabilities of the result.
im also messing around with sdl already so its not a big deviation from what im supposed to be doing
but, about sanitizers, they can check for much more bc they work during runtime, but also bc of that theres more delay between iterations
i also want to have a graphical representation of the structure of the code bc thats how my brain works and i want my tools to be dead stupid to use bc im a lazy frick and i hate learning (but i love inventing stuff and thats why i didnt reject that idea in the first place, kek.)
UBSAN does cause the compiler to do extra checks at compile-time. I've had it the other day, using some AVX intrinsics, compiling with UBSAN, GCC complained that on some paths the table I gave as input might be used uninitialized.
of course
but that check happens at runtime so you got more time between iterations
and its not realy a central goal to the enterprise anyways
the tool will be created for refactoring purposes. you could think of it as a specialized IDE.
the debugging capabilities are considered bc they should be a low hanging fruit
i mean, wouldnt you want a red flag to appear when you do an inattention mistake when youre at the 14th consecutive hour of coding?
bc i would. and thats why its going in.
>but that check happens at runtime
No, that error showed up at compile time.
nice. i thought ubsan only worked during runtime...
aah ok
but that sounds like an opt-in, no?
and its additional data that needs to be shoved around so it could slow down certain programs
idk...
in my view if its something that can be sorted out during/before compiletime, then it should
>Destroyed by if and switch blocks
took me a minute to get what you meant
and yeah, i thought a lil abt the problem in the meantimes and youre right
BUT
if your variables are as easy to inspect as clicking on em, it would help alot in maintaining code correctness
and when theyre not initialized within a condition or a switch, then its clear cut if theyre correct or not.
i think a green/yellow/red light type solution would still be of great value.
and it wouldnt be hard to provide the conditional statements chain up to that point to enhance workflow
in the case of a case statement you could provide the arborescence of the variable thats "cased" to the user to facilitate things further,now that i think of it
(ps. thats why i wanna do it on sdl2 btw. its for instinctual use purposes. at the core of the idea its a refactoring tool, but given the infrastructure thats already going intoit, it can be easily extended into a debugging tool. corectness of types check is reliable regardless of control structures. and initialization can be made into a red/green/yellow light system and still provide (massive i think) value)
https://reviews.llvm.org/D32199
You could always pick that up.
>llvm
nah, i dont have the skills yet.
also i think its the compiler's job,no? i would do that check when the source code is parsed.
after generics have been created.
if you wait for runtime to check, it increases the time between iterations
especially if you need to run a whole program at 10% speed before getting to the point youre actually testing
but also theres tons of text to parse, if you go the parsing way and so i think the plugin should gointo the compiler, while its tokenizing the code.
and finally, when youre at the llvm stage, you would lose type identity, no? only the width could be recovered
so a float going where a pointer is supposed to be would pass unnoticed,noticed, no?
>when youre at the llvm stage, you would lose type identity, no?
http://llvm.org/docs/LangRef.html#tbaa-metadata
>sanitizer
im distracted as frick
pls kindly disregard the part abt program speed
The best we have today is Go. Using anything else is pretty fricking gay.
>no NULL
hel yeah, I always wanted my mistakes to be silenced
>implicit conversion of arrays to pointers
>pointers that retain size information
looks like someone skipped his knr reps
also
>let's just add bloat to base language because that's what EVERY project that will ever be written in this language needs!
>preproc yapping
I didn't get how that's significantly different from what preprocessor already does, current preproc could use less bad syntax but it's already capable of everything described, only real downside is that compilers/linters/static analyzers won't properly check abstractions introduced via preproc metaprogramming which is solved with cpp abstraction mechanisms
all in all op is homosexual as per ususal
metalang99 already exists, maybe those features should be just made easier to use on preprocessor.
gcc extensions: computed goto, statement expressions, attribute cleanup.
Using those extensions it's pretty easy to implement using and defer.
Turn _Generic into actual switch statement on types.
>remove null pointers, all pointers should point during declaration to something valid that can be dereferenced, you just fixed all the segmentation faults
Zig
>extend struct definition with a concept of "nil" values that can be dereferenced without errors and are used in the same place where null pointers were used
optionals, and not part of struct definition but type definition
>remove the implicit conversion of arrays to pointers that point to the 0-index of the array and lose all size information, retain array size information and all array information when passed to functions
pointers either point to a single item *T or point to an array [*]T, there's also slices which are a pointer and a length
>overload the concept of pointers with the concept of "fat" pointers that retain size information and perform automatic bound checking during pointer arithmetic (think of it like what malloc and free already do when they know the size of the heap memory block the pointer points to but now it's a language feature), you just solved all the nasty pointer arithmetic bugs
again, slices
>drop the c preprocessor, maybe it made sense in the 70s, it doesn't make sense now, it's a relic of the past
dropped, but it has comptime code creation that is just the same zig syntax as normal code
>instead allow marked c blocks and functions to run during compile time (you can use a system similar to holyc) and allow regular c code to take the place of preprocessor, giving the full expressive power of the c (+ our enhancements) during the preprocessing step
yes, I just said that
>you just gave every programmer the ability to extend the language and the syntax with powerful ideas and abstractions like raii, smart pointers and possibly even more high level things like asyncronous programming, function decorators and more without any new syntax and without the ugliness and bloat of the c++ templating system
Sure, but it also has explicit allocators to avoid raii
Also it can import C headers and compile C code and call zig code from C. So you don't need to get rid of C, just build new code with zig right next to it.
You are dumb, these changes cannot be made to C. You would have to basically create a complely new langauge massivly different from C.
>You would have to basically create a complely new langauge
That's what he said at the end.
Yes, but it would be so completly different from C, the starting premice, take C, is redundant.
Just program in go moron
>2 MiB mandatory runtime; stop-the-world GC
Yikes just use a real language like Java or C# sweetie
>troon doesn't understand the performance or practical implications of his suggestions
Many such cases. SAD!
null pointers, all pointers should point during declaration to something valid that can be dereferenced
Dereferenced to what address? Call malloc requesting a block size that the runtime/OS cannot fulfill. You want it to return a valid ptr but it's physically impossible. So what are you returning? A ptr to a smaller block? Great, now you have a guaranteed buffer overrun. "Removing null pointers" is an expensive abstraction which has to rely on other error mechanisms, like exceptions, for its implementation in higher level languages. Because hiding them does not make them go away.
struct definition with a concept of "nil" values that can be dereferenced without errors
How does calling it "nil" help? It's a guaranteed buffer overrun.
the implicit conversion of arrays to pointers that point to the 0-index of the array and lose all size information
In other words: make arrays slower like they are in other languages. And also make it impossible to treat any block of memory as an array of any type, which is a key trick to writing fast code in C.
the concept of pointers with the concept of "fat" pointers that retain size information and perform automatic bound checking
So slow everything down, again.
>>drop the c preprocessor, maybe it made sense in the 70s, it doesn't make sense now, it's a relic of the past
Again, let's eliminate tricks that speed up code.
allow marked c blocks and functions to run during compile time (you can use a system similar to holyc) and allow regular c code to take the place of preprocessor
For what purpose?
>>you just gave every programmer the ability to extend the language
You can extend the language any way by writing your own compiler or preprocessor. Look up how Obj-C was implemented.
If you want a higher level language, use a higher level language. Leave C the frick alone.
The one thing I will agree with is that a process with rights to a ptr should be able to query the size and remaining bytes of said ptr at any time. The runtime has this information, as does the OS about any shared ptrs. So why the frick aren't size query functions part of the standard?
This would make it trivial to avoid most of the OMG MEMORY SAFETY!!! issues blamed on C without impacting performance in a negative way. I've always been baffled that something like totalSize() and remainingBytes() were not part of the standard from the beginning.
you basically created golang
the features you request have tradeoffs that make it unviable for the embedded programming c is used for
You are wrong, sir.
>take c
>remove the stupid curly brackets
>and procedures
>add a better type system
>remove the operator precedence rules
>add sets
>remove null pointers, all pointers should point during declaration to something valid that can be dereferenced, you just fixed all the segmentation faults
Brilliant idea homosexual. Now tell me how you declare an array of pointers?
>take c
>ruin it
kys op
Fixed your NULL pointer problem
char NullBuffer_[4096];
#undef NULL
#define NULL ((void *)NullBuffer_)
[code]
What if the buffer needs to be 4097 thou?