Find a flaw

Find a flaw

Other urls found in this thread:

stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c)
hack.org/mc/texts/classic-multics.pdf
twitter.com/NSFWRedditImage

It's shit.

Not sharp enough

Too perfect

C programmers

doesnt teach the lowest layer assembly or how is the memory managed in the OS

unsafe by design

itt: butthurt webdev's
don't you guys have another bloated web framework to go learn?

It has the power of assembly with the portability of assembly.

Teaches unsafe coding practices. Avoid like the plague.

The language itself is the source of 99% vulnerabilities because that's how prone it is to write unsafe code.

Programming language is an instrument - it's good only for its use cases.

depend on what u trying to achieve.

y the h8 m8?

i bought a copy of this and its just sitting here. is this book still up to date? has C not evolved since whenever the second edition was released?

No containers of any kind.

It teaches ANSI C, which is still the most common standard. The additions in C99 and C11 are relatively small.

gets()

You need to become a trashman in order to be able to use it.

Feels bad man.

Best book for leading C ?

Go back to Java pajeet

it turns college dropouts into smug assholes.

xD

What unsafe coding practices?

Overflows and friends. You have to watch for every single one of them.

does anyone have learn C the hard way in a pdf? libgen only has mobi and epub.

seconded

>learn C the hard way
That book is absolute garbage.

>doesn't teach the lower layer assembly
How could it? That's not in the C specification
>how is the memory managed in the OS
How could it? That's not in the C specification...

Oh wait, you're just spewing memes because you actually know nothing about programming.

>Oh wait, you're just spewing memes because you actually know nothing about programming.
Focus on yourself, not on others, you easily upset babby

Oh man. I have several complaints with C itself. In no particular order.

1) arrays are unlike anything else in the language. You can't explicitly pass an array of known size into or out of a function. If you try do, you will implicitly convert it to a pointer. C could originally only take arguments or return values that could fit in a single register. Later this restriction was removed and C gained the ability to pass structs by value but not arrays.

2) the implicit conversions are sometimes value-based and sometimes reinterpretations.

int -> float and float -> int are value-based. An integer will be converted to the float that is numerically closest to it (and vice versa).

int -> uint and uint -> int are reinterpretations.

If you have -2 as an int it gets cast to to some large integer rather than to 0 (the closest unsigned integer to -2 by value)

It would be nice if we just got rid of implicit conversion. Or do what Ada does and separate conversions and reinterpretations (I don't know Ada at all).

3) declaration reflects use leads to awful syntax for types like `int arr[4];` and `extern void (*signal(int, void(*)(int)))(int);` (source: stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c)

It would be better to make all of your type constructors (okay they're not called type constructors in C, but that's what they are) appear before the type, like in Go.

4) undefined behavior is not confined to any particular part of the language.

Some simple things like signed overflow are undefined (to allow for one's complement machines).

I think it would be a better approach to have a "core" of the language that does not have gratuitous undefined behavior and a larger inventory of types. That way you can make "potentially faster but unsafe" types that allow for more aggressive optimizations. That way undefined behavior is always opt-in and you can tell where it is.

The book is cool though. A+++.

>unsafe by design
Babby needs his hand held. Guess you're a Microsoft cuck then?

>sometimes value-based and sometimes reinterpretations
you're clueless m8; they're always conversions
>-2 as an int it gets cast to to some large integer
the conversion algorithm is documented
>source stackoverflow
ah, you're a """html programmer""" at heart
>simple things like signed overflow are undefined
yes
>(to allow for one's complement machines)
no; if it were only for that, it would be unspecified, just like the integer representation, you fucking ignorant
>to have a "core" of the language
yes, "JS: the good parts" was made for you
>gratuitous undefined behavior
you're completely retarded if you think it's gratuitous
>you can tell where it is
you'd obviously be incapable, if you can't "tell where it is" right now, when it's documented in the standard

You're autistic

>I got told
you sure did :^)

There are no flaws to be found

>getting embarrassed

To perfect?
C & C++ kick Java's ass

>C++
Don't lump that trash in with C.

Still better than Java ONCE you learn it properly (Which will take fucking forever)

C Programming: A modern approach. By far the best. Better than K&C for beginners IMO.

Underrated

>If you have -2 as an int it gets cast to to some large integer rather than to 0 (the closest unsigned integer to -2 by value)
It takes it modulo 2^N, donnit? -2 == M-2 (mod M) in normal arithmetic.

no namespaces
no classes
no templates
no references

if it had these things, the language would be perfect

>no namespaces
wrong
>no classes
no need, struct
>no templates
no need, macros
>no references
no need, pointers are more powerful
>if it had these things
let me guess, you're a webcuck

If you think "struct X" "enum Y" is a substitute for namespaces, you are retarded. If you think putting static in front of declaration and preventing linking, you're also retarded.

If you think macros are a substitute for templates you are utterly retarded.

>no actual string type

I really used to love C, but now I hate it. In theory, the language should be perfect...but it's too cumbersome to program large amounts of anything in it. If you are doing algorithms, you are better off with functional languages, and if you are doing a lot of string parsing and data handling you're better off with OO languages. So what is C good for? Maybe System Development, but that's like 5% of all coding. Most people I know who like C can't handle programs that are more than 12 files or more than 10,000 lines of code total. Maybe that's because C starts tripping over itself without having vigorous sets of eyes catching insecure pointers instead of it being done automagically in OO. For most code written, the issue is feasibility, maintenance and security...not speed. That's why C doesn't make sense for most applications.

>backpedaling
>damage control
sounds like you got told and rekt good, m8

strings

>Maybe System Development, but that's like 5% of all coding
First of all, "coding"? What are you? Some kind of Karlie Kloss web dev?

Secondly, some of us spend 100% of their time doing systems development and firmware development.

>no actual json type
that's how retarded you sound

>no namespaces
Fucks with the ABI
>no classes
No need. Data and functions are separate things.
>no templates
Far too complicated of a system for it to be appropriate for C, making it far too difficult to implement C. I assume you're talking about C++-like templates.
>no references
Come on. References are just shitty pointers.

It's my first post in this thread, how can I be back-pedalling?

>le there exists something simpler so why the need for abstractions

why not go all the way down to a byte type while we are at it and have nothing else

>to a byte type
Yes. It's called 'char'.

>No need. Data and functions are separate things.
That's fine, but having memory cleanup in the destructor is convenient

The book? It's pretty good.

The language? It's archaic and designed for 70s mainframes, requires you to manually manage memory and it's responsible for most security problems in today's code and the standard library is too small and as a side effect almost every project ends up reinventing the wheel.

REKT
E
K
T

I'm How does namespaces fuck with the ABI? In my world the ABI is short for "application binary interface" which is basically stuff like "the first argument goes into RAX, the second into RBX and the rest is pushed on the stack, while the return value is stored in RAX"... How the fuck does namespaces, a syntactic element of the programming language (aka compiler input) fuck with the ABI (aka the compiler output)?

>No need. Data and functions are separate things.
You obviously haven't seen the light that is functional programming.

>Far too complicated of a system for it to be appropriate for C, making it far too difficult to implement C. I assume you're talking about C++-like templates.
It's a valid argument for why not including it in C, but the question was flaws with C.

>Come on. References are just shitty pointers.
While references are synthesised to pointers, references are still good at ensuring code correctness. But I agree, no references is not a big deal.

>muh convenience
>muh css
fuck off webshit

Why can't people realize that no language is one size fits all? C is better at some things, Python better at others. For every task you have there is a language that would be better suited for it.

You're both missing the point. A string type is a glorified buffer type. String literals in C can be stored in different memory than data, where as string data types are buffer wrappers that copy string literals from that memory into data memory in runtime.

>How the fuck does namespaces, a syntactic element of the programming language (aka compiler input) fuck with the ABI (aka the compiler output)?
What exactly are you going to call the external symbol when a namespace is used?
In normal C:
void my_fn(void); is just "my_fn".
What does void crap::my_fn(void); become?

If you dislike convenience, why are you programming in C instead of assembly?

>where as string data types are buffer wrappers that copy string literals from that memory into data memory in runtime.
strcpy

who said I program in C? are you fucking mentally ill?

The same, this is resolved at the linker stage. The ABI remains exactly the same.

>The same
>I'm literally retarded
user...

>The same, this is resolved at the linker stage
That's exactly what I'm talking about: the linker.
Do you even understand what you're talking about?

Your point being? Do you think that strcpy has no overhead?

The ABI is literally "use this register for that, that register for this, return values goes into here" etc.

Linking functions into different memory addresses has nothing to do with the ABI.

See How does namespaces affect the ABI?

>Your point being? Do you think that strcpy has no overhead?
do you think the string type has no overhead when it has to allocate memory from the heap?

buddy...

>Linking functions into different memory addresses has nothing to do with the ABI.
How is "what symbol you jump to" not part of the ABI?
Why do you think that practically every language can easily link with C, but hardly anything can with C++ (and it's usually shoddy at best)?

>The ABI is literally
you don't know what the fuck you're talking about
>etc
that etc includes symbol names, you dumb shit

>do you think the string type has no overhead when it has to allocate memory from the heap?
No, my point was the fucking opposite... That a string type HAS overhead.

>How is "what symbol you jump to" not part of the ABI?
It's not part of the ABI, because you don't jump to fucking symbols. Symbols are created by the compiler in order to do linking at a later stage.

You can strip your executable entirely of symbols, the ABI would stay the same.

>Why do you think that practically every language can easily link with C, but hardly anything can with C++ (and it's usually shoddy at best)?
Firstly, this has nothing to do with the ABI
Secondly, it's not at all hard to link with C++. crap::my_fn would expand to __crap_my_fn in GCC and something slightly different with clang.

so why bother having an int type where you can just have char[4]

>something slightly different
>different
you don't say!

because an int varies in size depending on the machine

>It's not part of the ABI, but then again I'm a webshit so I don't know what I'm talking about

Oh wow, you guys sure told me with that greentext.

yeah, you got told pretty hard; try not to be retarded next time

Does an int remain the same size if you use a 32-bit or 64-bit OS?

holy fuck you are autistic

it depends

nothing a good #define MACHINE_INT_SIZE 4 can't fix ;^)

>systems programming is only 5% of development therefore I will spend 5% of my time doing it

i'm not even him but you are clearly autistic

>muh codes

Who are you quoting?

t. senior fizzbuzz developer

...

>not-him-but meme
ishyggy

But I didn't even write that!

Why the fuck are you replying out of context and making up stuff then?

Because It's the Internet and I can do whatever the fuck I want, shitbag.

>It's archaic and designed for 70s mainframes
I don't like the "70s mainframes" excuse. PL/I is from the 60s and used for systems programming and it isn't susceptible to a lot of these problems. The Multics kernel and tools were written in PL/I so it can be used for all the things C is used for.

>and it's responsible for most security problems in today's code
The makers of Unix used PL/I when working on Multics before they made C, but Unix wasn't designed to be secure because it wasn't a professional project. Crashing was fine because it was their own software they had the source to, so they could fix problems whenever they wanted.

This is worth reading.
hack.org/mc/texts/classic-multics.pdf

>you're clueless m8; they're always conversions

I don't think I explained my point very well. Sometimes you are applying a different interpretation to the underlying bit pattern. For instance, the conversion from signed to unsigned integer. In order to get the same behavior when converting a float to an integral type you have to do something like this:

i = * (long *) &y;

The implicit conversions between floats and integral types are different. A float will get cast to an integer of the given width/signedness that it is closest to numerically and vice versa.

> yes, "JS: the good parts" was made for you
> you're completely retarded if you think it's gratuitous
> you'd obviously be incapable, if you can't "tell where it is" right now, when it's documented in the standard
There's no need to be rude. Undefined behavior allows the mapping from C to the instruction set of the machine you are working on to be simpler, at the cost of some loss of portability.

It is not simple to analyze a C program and see where a conforming compiler could do something completely different from what you're expecting. Hence you get weird shit like bugs that only occur at higher optimization levels.

What's PL/I like? How does it differ from C?

array decay, i.e., mandatory conversions of sized arrays to raw pointer when passed to/from functions.

to all you morons, this is not the same thing as missing dynamic bounds checking on random access indexes.

Are there languages that are similarly low-level to C that lack array decay but allow you to write functions that are generic in the length of the array?

IIRC pascal allows you to pass arrays into and out of functions, but an array of 10 ints and an array of 9 ints are completely separate types.