*overflows your buffers*
*overflows your buffers*
David Gutierrez
Zachary Morales
>not using scanf
Easton Bell
>accepting user input
Brayden Moore
C is a powerful tool. If you don't know how to use it then don't use it, it won't fix your mistakes instead of you.
Levi Nguyen
*Cuts off your fingers*
Whats your point? If you are retard saw your pipes with toothbrush. I believe it wont do any harm to you.
Jordan Lopez
>this is the only model of disc grinder that's always cutting people's fingers off, even experienced users'
>I'm sure the problem isn't the tool though, it must be the people using it!
Nathaniel Mitchell
>language designed to be a light abstraction over assembly
>achieves its purpose of cross-compatibility with any architecture while still providing near-assembly granularity and some small but helpful abstractions
>does nothing you don't explicitly tell it to do, providing the necessary control over exact behaviors to make it suitable for software not running in an OS, or OS implementation
most of the shit you retards complain about are the very things that make C relevant
Jason Johnson
>undefined behavior: the language
>achieves cross-compatibility
>provides control over exact behaviors
So soon into 2019 and we already got such a strong contender for most retarded post of the year!
Elijah Gray
undefined behavior is the unfortunate side-effect of a language whose entire runtime system can be implemented in a couple dozen instructions on virtually any architecture. Are you this retarded or just trolling?
Nathaniel Davis
>even experienced users'
This is an inaccurate analogy though. If you use C and write code that contains buffer overflows, that's no problem, anyone can make that mistake. But in this day and age, with profiling tools like valgrind available, if you use C and RELEASE code that contains buffer overflows, you are NOT an experienced user.
Colton Peterson
There's no good reason this should be UB.
uintptr_t x = 1;
void *p = (void*) x;
// you don't need to dereference it, this is already UB.
C has a lot of unnecessary UB that exists beyond the obvious & necessary stuff like dereferencing a null pointer.
Noah Morgan
>// you don't need to dereference it, this is already UB.
No it's not.
Adam Miller
Yes, it is. All pointers within a program must either point to a valid object or one past the end of an array. If it doesn't, it's UB.
wiki.sei.cmu.edu
Robert Turner
>Addition or subtraction of a pointer
Mason Rivera
1 + (char*) 0
Very well, we have this then.
Aaron Rogers
>yup, all those people working on Linux, Apache, OpenSSL, and other projects simply do not know what they are doing!
Logan Foster
C is literally the reason so many security issues exist today.
It's incredibly funny to see people patching up shitty C code for decades, quite literally treating the symptom instead of working on the cause.
Carter Adams
you must be completely fucking retarded. The rule you linked to has nothing to do with your statement, even if your statement is right. That standard specifically refers to a pointer that was made to an object or an integer type. You didn't make a pointer to an integer or object. You made a pointer to 1, not a pointer to an integer type or object containing 1.
The rule you mentioned says that this is UB:
int x = 1;
int *y = ((&x) + 1);
And the fact that this is UB makes perfect sense. There are plenty of reasons why this should be UB, including address space limits and pointer-width overflow. Exiting the limits of an address space and pointer-width overflow are both things that may or may not happen on any given machine, based on the width of its pointers and the limits of its address space.
If this behavior was explicitly defined, C would not be directly compatible with architectures whose memory model differed from the new rule. Thus, these machines would either be outright incompatible with C, or some kind of hack would need to be implemented by the compiler to resolve the UB on this specific architecture, causing performance to grind to a halt, and transparency throughout the entire language to be lost.
As has been said in this thread already, C leaves certain behaviors undefined because they vary from platform to platform, and the only solution would be to implement a more sophisticated runtime system that defines address spaces and pointer widths, among other things. The end result would be a slower and less transparent language, which obviates every advantage and use case of C.
Joshua Hill
Whats a pointer? t. c# pro
Anthony Turner
*takes 10 hours to compile, overflows your buffers, makes your project so complicated that no one can maintain it*
Ryan Bell
A reference type except it also supports arithmetic.
Alexander Hall
samefag
Angel Gomez
based and redpilled
Blake Moore
C++ is at least safer than C.
Benjamin Rodriguez
continued from samefag
Jace Rogers
Its the side-effect of having a silly standard which prioritizes a simple compiler over a safe one.
Isaac Mitchell
a path to hell paved with performance considerations
Logan Cook
pic related
>safer
>less portable, less performant, less transparent, and more abstraction without purpose
languagetutorial.org
Parker Bailey
>less portable, less performant, less transparent, and more abstraction without purpose
So which of these does this UB fall into then
>An unmatched ' or " character is encountered on a logical source line during tokenization.
UB only exists to improve performance and for some edge cases where the grammar is undecidable otherwise.
>languagetutorial.org
Is this supposed to be a joke, I don't get it Pajeet?