Why C is sucks?
???
>>53285332
int array[] = {1, 2, 3, ,4 , 5, 6};
printf("%d", sizeof(array));
output: 4
why not 24 ??!
>>53285384
because the name of an array is a pointer to its first element. array[subscrupt] is just some syntactic sugar for pointer arithmetic. Memory management is your responsibility in C, the compiler doesn't keep track of how much you have, and its your responsibility to free it when you're done.
http://steamcommunity.com/groups/godisadog
>>53286133
is learning memory management(C) important? coming from Java it seems like i don't have to worry about memory management at all but i also don't want to be one of those script kiddies cos programming is getting mainstream these days, people with java/python skills will probably be way too much
>>53285384
It's giving you the size of an int* kiddo.
You need to pass in the number of elements too.
>>53286171
You can't write any significant C at all without a good understanding of memory management. Most of it's just "remember to free() what you malloc()", but it's important to know about allocating on the stack vs the heap, how things are laid out in memory, and so on. C compilers are old-style "I assume that you know what you're doing" kinda tools.
>>53286133
>>53286172
>>53286280
I know what's going on with the code but what I mean is why the array not treated like real array like this: array[24] ???
why isn't this in C standards?
>>53286404
>why isn't this in C standards?
actually the behavior you find baffling IS what the standard says it should be. If you want an array of 24 separate bytes, make one. if you want an array of six ints, usually you want them to be six ints (which happen to be four bytes each) so you can just say something like x = array[3]; and get the four-byte int at that spot. You can do it manually, too, if you want:int* array;
/* allocate 24 bytes - space for six ints */
array = (int*) malloc(6 * sizeof(int));
>>53285324
It doesn't.
You just have to remember that in C your key abstraction is the machine itself, while in other hlls it's the system or process you're modelling.
C is the right tool most of the times that you want that to be true.
>>53286491
It's important to note the difference between the stack and the heap when comparing these two cases though.
>>53286404
I'm pretty sure an incomplete array is just a pointer. If you think that's bad, try using sizeof on an array parameter.
>>53286541
C is the wrong tool all the time.
>>53286491
why would you use
>array = malloc(6 * sizeof(int));
instead of
>array = malloc(6 * sizeof(*array));
Also why are you casting malloc?
K&R C or Modern Approach to buy?
>>53287271
malloc needs to be casted, otherwise you will just get void pointers
>why would you use
>array = malloc(6 * sizeof(int));
instead of
>array = malloc(6 * sizeof(*array));
try printf("%d, %d\n", sizeof(int), sizeof(int*)); on multiple machines, they are not always the same size.
you want to allocate space such that an int will fit into each space. in this case, 6 spaces. if you wanted to store an array of pointers to an int, then you would be fine.
>>53287529
Congratulations, this is the most retarded post on /g/ right now!
>>53285324
no namespaces
no operator overloading
poor type safety
poor const system
>>53285324
https://www.youtube.com/watch?v=KlPC3O1DVcg
>>53287697
wasn't there a rumor that he purposefully invented C++ to set back programming
>>53287727
No, ctards were so retarded that they took a joke as if it were reality. The truth is that the invention of C literally, provably set back programming over 50 years. To this day, we still don't have feature parity with forth, apl, lisp, or bcpl even though everyone obviously want these features since every year or so a batch of them are adopted in every other modern language.
>>53287754
>forth
Too powerful for it's own good.
>apl
I'm not buying a programming keyborad
define min(x,y)( (x)<(y)) ? (x) : (y)
main()
{
printf( "%d\n", min (3,6) +1);
}
why does it return 3?
>>53287566
>I'm so bad at programming I need safety nets and high level spaghetti code bullshit that reminds me of BASIC
>>53287754
I've programmed in C,it was my first programming lanuguage in fact, but I'm definitely not a C hacker.
My impression is that of a laguage that filled a niche at the time, and then it took off like a virus in the 70's-80's.
It's not a very good language, it comes from the "good enough" tradition of Unix.
It should be now possible to design a system programming language NOT in the tradition of C, but nobody seems interested.
>>53285324
If we are talking about developing the infrastructure everything works on, C sucks because you suck at programming.
For everything else it sucks because it's just inconvenient, the development time is an issue in end user programs.
>>53287806
>no #include <stdio.h>
>no # before define
>parenthesis in the wrong place in define (the one after <(y) should be at the end
This is why kids hate C, they suck at it.
>>53287837
Linear types are a great idea (ats, rust, idris, f*), though unique types are good enough (clean, etc.) to bring the same semantics as C with none of the lack of safety. From there it's possible to add any paradigm or abstraction you want without performance penalties or loss of safety.
C never actually filled a niche (as bcpl, forth and fortran already existed), it just happened to be pushed by the unix folks as the Next Big Thing (tm). It's basically 70's rendition of java in virtually all regards (high-level, but not as high as what can be, slow (it only got non-shit compilers much later), unsafe, verbose (thankfully modern compilers are good enough that we can strip 90% of annotations safely), pushed by a single large corporations, and learned by every monkey because pushed -> learn to get job -> people know it -> pushed due to low training costs). Unlike java, nobody has ever been allowed to call it shit (as it was).
>>53287806
also
>int main()
>return 0;
Baby's first C program?
>>53287906
It's not a good idea, but the compilers these days are usually smart enough to include the header by themselves.
>>53287831
Yeah, abstractions are for plebs. Who needs while/for/do when you have a perfectly good goto statements
>>53287948
Bullshit.
>>53287906
does this fix your autism?
>>53287957
Try it yourself with a simple program.
The program will work, but you'll get a compiler warning.
>>53287958
Because it will expand to ( (3) < (6) ) ? (3) : (y) + 1
>>53287958
>including stdlib for the unnecessary EXIT_SUCCESS (EXIT_SUCCESS is always 0)
>still not fixing the parenthesis
>still not using int main
>calling CORRECT FUCKING C CODE "autism"
Are you 12?
>>53287965
mind = blown
>>53287969
>EXIT_SUCCESS (EXIT_SUCCESS is always 0)
how do you know?
that's not very multiplatform of you to assume
>>53288026
Keep in mind that you should never actually do this.
Something about performance? I think?
>>53287948
No, it's called "undefined behavior." It might work, but it shouldn't.
If you can't even program correct fucking C, just stop even trying to be a programmer. Seriously, it's not fucking hard.
>>53287969
>doesn't know C
>calls others retarded because they actually know C
C is a lovely language if you take it for what it's worth. I personally prefer C++ because
>muh OO and
>muh functional programming
but C is probably one of the most elegant languages in the history of programming. Few other languages span such a breadth and depth in terms of talking to a computer without the labrynthian complexity best displayed by C++.
>>53288058
>doesn't know C
Those are all CORRECT C ACCORDING TO THE STANDARD FUCKING C. You fucking dumbshit baby.
>>53288054
no it's bad to assume your compiler knows wtf your doing.
thankfully newer gcc builds should throw error in the future
>>53287918
>C never actually filled a niche
What if the niche is smug Unix weenies?
>(as bcpl, forth and fortran already existed), it just happened to be pushed by the unix folks as the Next Big Thing (tm).
ehehehe
>It's basically 70's rendition of java in virtually all regards
No, Java was somewhat designed.
>(high-level, but not as high as what can be,
slow (it only got non-shit compilers much later),
a lot of C idioms seem designed to circumvent shitty compilers from the 70's
>unsafe,
Don't even get me started on this
>verbose
> Unlike java, nobody has ever been allowed to call it shit (as it was).
They did, but the Unix religion won
>>53287697*YOU* are full of bullshit.
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
>>53288071
>>53287958
is correct C according to the C standard. Just because you don't know C does not mean you're an expert on C. I have no idea why I have to inform you of this fact.
>>53288054
It's got nothing to do with performance and everthing to do with portability. just because your shit builds on some four year old gcc release doesn't mean it'll build on some other arbitrary clang release or whatever the hell people use these days. you should always be explicit when talking to your compiler.
>>53288089
Is there anything linus was ever not wrong about?
>>53287969
it's from a book and my question is why it returned 3 meant it complied correctly, i didn't want to write down unnecessary code on phone. So yeah you have autism.
>>53288089
hello, linus
>>53288089
C is genuinely a good choice for a kernel though.
It just werked for what it was intended to. This isn't the 60's bell labs programming on pdp-11 where 64k memory was huge
>>53288166
It's a horrible choice for kernels because it contains no tooling or primitives to ensure safety or correctness, which are beyond important at such a low level.
>>53288223
Yes, but it's as close to the metal as you can get without going into assembly language.
>>53285384
it does return 24.
>>53287806
because you fucked up the macro.
>>53288240
That's irrelevant since C requires OS primitives to actually perform its "low-level" operations (i.e. you'd have to bootstrap, whether or not you use C, C is only low-level because it's mapping close to OS interrupts, but since you wrote the kernel yourself, you already have the access-level you want no matter what language you use). Languages like forth are also very close to the metal yet expose much higher-level constructs and safety, too. The likes of ATS can perform arbitrary low-level operations in complete safety (although ATS's ugly as shit).
>>53287754
Congrats asshole you're the best troll i've ever seen.
I kek'd
>>53288374
lmao butthurt
>>53288374
>SICP was too hard for me but K&R was perfect
>>53285384
but this does output 24
>>53288405
>>53288434
>samefag
Your retard is showing.
>>53288522
>not even the same person
Ctards everyone!
>only one person can possibly be less retarded than me!11
>>53288518
Is it just my impression or there are people on /g/ who considers themselves C programmers just because they passed a college course?
>>53288537
>>53288434
>>53288405
>double samefagging
>being this retarded
grow up m8
>>53288576
If they took a class on C probably, I think you're a C programmer if you write C regularly. If it's been more than a year you /used/ to be a C programmer.
>>53288652
If you wrote C everyday for 10 years but its been 10 years since you've worked you are more than likely still a good C programmer so it wouldn't be used to be.
>>53288672
>If you wrote C everyday for 10 years but its been 10 years since you've worked you are more than likely still a good C programmer so it wouldn't be used to be.
A good C programmer with a 10 years' gap in understanding of how modern C has evolved since then.
>>53288679
I meant five years but still, you'd think he would have the ability to jump in and get up to speed quick even after 10 years.
>>53288704
I agree, I'm just pointing out that C also changes over time
>>53288679
how has modern C evolved in the past 10 years? give examples to support your argument.
>>53288723
Not the samefag but one thing i'd say is definately 64bit programming. The underlying assembly is completely different.
>>53288723
https://en.wikipedia.org/wiki/C99
https://en.wikipedia.org/wiki/C11_(C_standard_revision)
>>53288723
the _Generic keyword.
>>53287547
(x = â—¡ =) happy to oblige, also you're fat in real life.
>>53288089
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html
>>53285324
you're right C sucks
>ruby for life LMAO xDDD
Buffer overflow.
>C
>bad
Well, I wouldn't say C is bad, I mean it's used in the likes of the linux kerSegmentation fault
>>53287271
>sizeof is a function
you don't belong, m8
>>53287948
>include the header by themselves
never happens
>>53288052
>how do you know?
by reading the standard, you fucking monkey
>>53287529
malloc doesn't need to be casted
you don't get void pointers because you're not assigning it to a void pointer
>>53288100
>correct C according to the C standard
false
>>53292700
>facts are false
>pls sir i no c sir pls hire me sir
>>>/india/
>>53288751
nothing to do with C
>>53287529
everything in this post is wrong.
>>53292701
>I don't know C so I can't explain what happens
anon...
>>53292715
>facts
you only think that because you don't know C
>>53292761
ok pajeet
>>53292786
>ok
great; admitting your lack of knowledge is the first step
>>53292882
ok rajesh
>>53292895
>butthurt for getting told so easily
Top keks!
>>53292895
what is this shit flinging contest even about at this point?
who knows what and doesn't know something else?
>>53292929
Summary: the big dick playa that knows C rekt the unsuspecting "screen pic" faggot that doesn't.
>>53292925
ok pajesh
>>53292929
Some retard who doesn't know C thinks he is an expert at C for not knowing what the standard says, causing him to fly into an impotent rage as other people actually know the C standard and write valid C programs. He then goes around recommending C as if it were a usable language, despite the fact he literally doesn't even know C.
>>53293001
This guy? >>53287958
lmao whata bunch of fuckin nerds
>>53293016
>animooooooooooooooooooooooooooooo
>>53293013
No, this guy is correct.
This guy: >>53287969
>>53285324
Which one is sexier?
C:#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}
C Sharp:public class Hello1
{
public static void Main()
{
System.Console.WriteLine("Hello World");
}
}
>>53293029
>No, this guy is correct.
But that doesn't look correct at all. Do you even know enough C to have an opinion on this?
>This guy: >>53287969
All he said is true.
>>53293050
OCaml:let () = Printf.printf "Hello World\n"
>>53293087
Samefag harder rajeet. Maybe learn C sometime.
>>53287529
>malloc needs to be casted, otherwise you will just get void pointers
>>53293099
I actually know enough C to recognize the problems with that code. You should take your own advice.
>>53293050
Second one.
>>53293029
>this guy is correct
>this guy
anon, we all know samefagging when we see it
>>53293050
first one is both too verbose and incorrect
>>53293163
explain
>>53293050
first one
clear and concise, except for that int line what the hell man
>>53285324
old
>>53283128
nope
>>53288275
i wanna buy a set of pine64's but i'm leaning to a t1000 sun blade instead... more cores
>>53293132
The irony is palpable.
>>53293181
implementation defined main definition; use of printf instead of puts
>>53293266
>I don't know C
>>53293275
main definition is standard-compliant.
>>53293289
>I'm from india sir I know good C and kindly do the needful
>>53293290
>standard-compliant
what standard? not C, anyway
>>53293304
>projecting this hard
>>53293275
using printf isn't incorrect, it's just not ideal for a simple string ending with a newline
>>53293460
never said printf is incorrect
>>53287969
>calling out others on unnecessary stuff
>insisting on using int main
this guy
>>53293504
so using printf over puts is being too verbose?
i'd say the problem lies somewhere else than verbosity
>>53293635
>printf over puts is being too verbose?
obviously; do you know what verbose means?
>problem lies somewhere else than verbosity
it has that too, as already stated
>>53293559
>this guy
wants correct code? you disagree with that?
>>53287754
>muh features
You can have them when you can implement them efficiently and thread-safely in kernel-space. Till then, C will remain the language of choice for system software.
>>53285324
C doesn't suck for the same reasons the internal combustion engine doesn't suck
doesn't change that fact that it's long overdue for a replacement
>>53293128
>he doesn't cast his mallocs
Do you also have unprotected sex with niggers?
>>53293559
>his OS doesn't have exist statuses
>>53293780
>not just calling your own functions straight from _start()
Pleb
>>53293667
>obviously; do you know what verbose means?
yeah but i don't really see how a newline escape sequence is too verbose
>>53294023
do you fail to see how "puts("Hello World");" is shorter than "printf("Hello World\n");"?
btw, the return statement is also useless
>>53285384
4 = 6 times an integer?
The C Compiler assumes you completely understand the core concepts of the Cee-Lang Virtual Machine, as well as how most classes of standard "integer" behave on your native CPU architecture when applying common arithmetic instructions.
Provided you know these 2 core concepts you've mastered C. That's really it.
>>53294082
I see it's shorter but the difference is so minimal only a true autist would consider the latter "too" verbose
>>53294139
I have.
>>53294238
>I see it's shorter
great, that was the point; backpedaling is not required.
would you prefer to write "System.Console.WriteLine(String.Format("Hello World"));" instead in the C# version?
>>53293757
>I literally don't even begin to have a clue about what I'm saying
Typical ctard.
>>53294139
No, it's impossible to master C. Proof: even the greatest minds in the world still cause buffer overflows and leak memory.
>>53294663
No, I don't.
>>53294449
that IS the C# version
>>53294727
are you mentally ill?
>>53294663
Who says they weren't rushing, or calling other's code?
>>53294797
who says a language is usable if it requires literally infinite time to make a non-dangerous program with it?
>>53285324
Header files for no good reasons.
>>53294817
>literally
anon...
>>53294818
>I don't understand C
you're not entitled to an opinion then
>>53294911
I most likely understand C and compiler construction much better than you ever will.
Well, there is no good reason for them to exist.
They don't improve the implementation of linking, the ease of writing stuff or distributing libraries and they don't reduce the performance or memory size required for compilation.
A good module system with can beat the header/implementation thing in every regard.
And even if you wanted shipped headers for your own moronic reason, there is no reason to require them on all other occasions.
Reasons like these are why K&R should have offed themselves instead of reinventing CPL in far worse.
>>53287958
Compile the file with -E and look a the resulting file in a text editor then you understand
C BASICS THAT KEEPS YOU FROM GETTING REKT:
- compile your program with gcc and use "-ansi -Wall -pedantic -g" , look up what it means
- install nemiver
- debug your program with nemiver ./programname
- install valgrind
- When youre allocating memory use valgrind ./programname to check for leaks
- use "man fuctionname" f.e. "man printf" or use "man libraryname" to get the manual for a certain library like f.e. "man stdio"
>>53294911
>>53295135
Oh and before I forget, if you wanted to ship them so badly because you were too retarded to document your library properly it could have designed to generate those header files, but they fucked that up, too.
>>53286916
yeah the stack, man! Hmmm yeah the stack, and that heap is real important too right, man?
>>53295135
>the ease of writing stuff
Improves significantly with headers.
>or distributing libraries
Significantly easier to distribute libraries with headers since you can distribute the library blob and the headers without the implementation, allowing people to code against the API without runtime dynamic linking and function pointer capture hacks.
They also significantly improve documentation because you have the API and documentation in one place separate from the implementation, meaning a lot less text bloat in the implementation files and a centralized, easy to navigate documentation and API reference.
A good module system will literally always be implemented with a header/implementation pair, whether or not they need to be put in different files.
Not to mention that header/implementation separation allows hot-pluggable implementations.
TL;DR: you obviously don't know the first thing about C, compilers, or programming languages.
>>53295135
you probably don't understand C or compiler construction if you think your high-level modules would ever work securely and efficiently as headers do
>>53295135
>better than you ever will
serious sign of mental retardation
>there is no good reason for them to exist
you don't know anything about C
>They don't improve bla bla bla bla
do they simplify the language?
>good module system with can beat the header/implementation thing in every regard
except simplicity and reliability
>shipped headers for your own moronic reason
you don't make any sense
>no reason to require them on all other occasions
read some more about C
>>53295311
>>53295341
lol you guys dont know anything about anything it a miracle youre able to write
>>53295222
>worthless drivel
tldr
>>53295406
OK pajeet.
>>53295406
kill you're self
I found this function qsort in my C standard library
Is it botnet?
>>53295456
>kill you're self
>you're
>>53295459
yes.
use qsort_r instead.
>>53295481
newfag fuck off.
>>53295481
>I don't belong
m8...
>>53295459
It should actually be renamed ssort because it's slow as fuck, unlike the C++ std::sort.
>>53295519
>unlike
bwahahahahaha
>>53285324
>Why C is sucks?
lots of needless small flaws that add up
> unhygenic macros
> array/ptr decay
> in-band (null-terminated) control for C strings
the language doesn't offer any safe abstractions, so safety is a "design pattern" for shit as simple as passing and iterating through arrays.
and the worst thing is tha C fags can't understand that the language didn't need to bounds checking on every single element access to be 95% safer.
>>53295536
>bbut facts doesn't real!?!
ctards everybody
>>53295551
>muh safe abstractions
>I don't need performance
faggots like you should know their place and stick to slow, managed languages
>>53295551
>in-band (null-terminated) control for C strings
I'll never understand what's so bad about this. I understand the ""evil"" about the null sentinel, but the whole point of C is that if you want to store the size of a string along with the string itself, malloc & structs are available.
>>53295568
>facts
bjarnecucks actually believe this
>>53295551
>decay
>I don't even know what the fuck I'm talking about
>>53295605
maybe it's you who doesn't know
>>53295605
Literally any person with even remote knowledge of C knows what he's saying, which by definition must mean you don't even know the first thing about C.
>>53295613
who knows? maybe "decay" is mentioned in the standard, right? it's not like you've read it or anything!
>>53295643
>Literally
ask me how I know the rest of the sentence is not worth bothering
>>53295590
> keeping an array's element count associated with the array when you pass it to a function is an extravagence
>>53295551
>C fags can't understand that the language didn't need to bounds checking on every single element access to be 95% safer.
proven in your first reply
>>53295605
neo-/g/: where everything people don't understand is equivalent to rotational velocidensities
>>53295661
I guess I don't understand what being "in the standard" has to do with anything. the post was "criticisms of C", not "undefined shit not in the standard that I hate about C"
maybe put down K&R and pick up a book on comprehension
>>53295686
>I'm inbred and nobody can stop me!
>>53295715
>I don't understand
thus, not entitled to an opinion on C
>>53295706
>got told
>must control damage
m8...
>>53295722
literally?
>>53295764
It's funny because he understands C better than you ever will.
>>53295828
>than you ever will
the mental illness is strong here
>>53287754
>Feature parity with what are essentially subsets of c
Are you retarded?
C is how you program Von Neumann machines. All other languages are abstract simulations.
>>53295828
>he understands
>>53295715
>I don't understand
TOP FUCKING KEK!
>>53288307
>Languages like forth are also very close to the metal yet expose much higher-level constructs and safety, too.
You've clearly never used Forth.
Forth has zero type checking and it doesn't even check the 'parameters' passed to words (words just assume they have what's needed on the stack, and when they return the caller again assumes the stack is balanced, all with zero compile time checking).
Further more, the return stack is completetly exposed and even encouraged to use for arbtrary data, meaning it's extremly easy to introduce arbtrary code execution if you're not careful.
>>53295551
>> array/ptr decay
ah, the first and most correct response to OP's question, guaranteed to start flame wars every time, since it's true. (and it only took 170 responses this time)
>>53295590
>>53295605
>>53295661
>>53295686
for all you slow children, here's the deal:
> fundamental semantic trait of C is pass-by-value
> can't do this sanely with buffers
> pointers can be passed by value and operated on with [] syntactic sugar to get at elements
> type system is very poor, so making arrays (ptr, len) tuples with automatic casting (e.g., static sized int[N_ELEM] getting length fields added on call to a function) was not reasonable
> every time an array without in-band termination is passed to a function, size information is lost unless passed as a separate un-attached parameter
> people fucking this up all the goddamn time is how we get HEARTBLEED, etc.
> passing length params is a pain in the ass, so C strings defined as in-band null terminated
> which causes string overflows every time an idiot makes a bad assumption about buffer and input sizes, etc.
The bigger sin IMO was actually probably pass-by-value, instead of pass-by-(default-const-)reference, with ABIs allowed to optimize as pass-by-copy for small const references, since that has infected many other languages that managed to do buffers more sanely.
>>53295934
>muh dream architecture
well, reality needed a practical language and that language is C; keep jerking it to lisp machines, pedofag
>>53295934
>>> array/ptr decay
>ah, the first and most correct response
bwahahahaha, do you have any idea what you're talking about, m8? there's no such thing in C
>instead of pass-by-(default-const-)reference, with ABIs allowed to optimize as pass-by-copy
this ain't memejs, you idiot, things need to be efficient!
>other languages that managed to do buffers more sanely
typo for "slowly"? hahahahaha
>>53295934
>with ABIs allowed to optimize as pass-by-copy for small const references
You could only do that for inlined functions, because the callsite couldn't possibly know if the function will take the address of the reference (which is supposed to be the address of the referenced object, not of the local copy)
>>53296060
>there's no such thing in C
bud ...
>>53296090
yes, bud, it might come as news to you; read the standard for more shocking insights! you won't believe it when you're done and haven't seen one mention of "array/ptr decay"
>>53296136
of course not -- it's just a phrase to describe some details (which *are* in the standard). read some more:
https://lkml.org/lkml/2015/9/3/428
>>53295605
>decay
>>53296060
>no such thing in C
good lord, you dumb niggers...
"array decay" in C just means that you can't pass an array through a function argument without losing any size information the caller may have had.
> i.e., array arguments "decay" into pointers inside the callee
workarounds can obviously be done with separate length args, null termination, etc., but even "good" developers fucking this up is by far the single biggest source of security exploits in C programs.
keeping the pointer and length tied together at the language level doesn't cost a program any performance penalty since a safe program always needs to track both anyway.
>>53296187
>talks about standard
>uses 3rd party discussion link to prove his point
how about linking to the standard, you massive impressionable faggot?
>>53296187
>just a phrase to describe some details
codewords for "I don't know the actual standard terminology because I haven't looked at it but I head this shit on them webs"
>>53296204
>array arguments "decay" into pointers inside the callee
not even close; please stop citing random blogs and just read the standard
>>53295909
Found the clinically retarded.
>>53296204
>doesn't cost a program any performance penalty
>safe program always needs
and that's how you get lagdroid
>honestly guise, some more checks enforced every fucking time for no reason won't slow things down at all!
>>53295591
>I'll never understand what's so bad about this. I understand the ""evil"" about the null sentinel, but the whole point of C is that if you want to store the size of a string along with the string itself, malloc & structs are available.
I'm not a C programmer, so take what I write with a grain of salt.
If I wanted to create a more sane string type in C I would have to write something like:
typedef struct{ char *str;
size_t length;
} string;
But then wouldn't I lose all those functions that assume null terminated strings?
>>53296262
>not even close
As usual, cfags literally don't have a single clue about the language they suck the cock of.
>>53296262
>>53296241
>>53296225
just read it -- it says everything I already knew: arrays aren't pointers but decay into a pointer which point to the beginning of the array. who knew?
>>53296204
>safe program always needs to track both anyway
Not ALL THE TIME in ALL THE PLACES though. You don't need to pass around everywhere the length of a sha-1 digest buffer, do you?
>>53295591
Then none of the C string functions would work with your format, and as a result you'll have to rewrite the entire C standard library. Oh, and also every library that uses any features from the C standard library, which is all of them.
>cfags
>retarded
Choose two.
>>53296317
why do you assume that you should remove the null sentinel when you do this? surely you'd keep them for the inevitable function which needs just a regular old c char array. c++ does this too
>>53285324
>procedural programming
>in 2016
seriously now, C itself is ok; pointer arithmetic is clumsy but once you get the hang of it it gets manageable. i think c biggest problem are the libraries that use different coding styles; stuff like returning a int with error code or returning -1 for error code and ERRNO (errno is pretty bad); also if you are making syscalls get ready for headaches since they are constantly getting broken or are already broken, and people don fix it
>>53296328
you forgot to include a citation that proves your point
>>53296350
>Then none of the C string functions would work with your format
they aren't just regular char arrays, they are a structure. you wouldn't pass a structure to a function expecting a char pointer type, would you?
>>53296377
You forgot to not get lobotomized.
>>53296380
Exactly. Glad you understand that your argument was beyond retarded.
>>53296333
>just read it
I did
>everything I already knew
orly? you ALREADY knew? what blog post do you know it from?
>decay into a pointer
where does it say that? surely if you ALREADY read the standard you can quickly point it out
>>53296405
i don't think you understand what you're even arguing about.
>>53296410
>where does it say that?
ISO Sec. 6.2.2.1, Sec. 6.3.2.1, Sec. 6.3.6
>>53296425
Since you are retarded, maybe reddit would be more your pace.
>>53296369
>pointer arithmetic is clumsy
it's just fucking awesome; no language without pointer arithmetic will ever be taken seriously for low level programming
>>53296387
>I don't have one
expected
>>53296443
mirageos is written entirely in ocaml - an actually competent language. It is also the most popular microkernel by far.
>>53296262
>>53296410
The standard calls it "conversion", and other people call it "decay" to reflect that extra information is only lost.
> §6.9.1(10):
> On entry to the function, the size expressions of each variably modified parameter are evaluated and the value of each argument expression is converted to the type of the corresponding parameter as if by assignment. (Array expressions and function designators as arguments were converted to pointers before the call.)
>>53296437
are you even aware there's a C string library which does exactly what I said? i never said that a packing a char array along with its size in a struct would be able to be coerced into a char array.
which is the whole point of C -- gives you the ability to define shit the way you want. don't like depending on null sentinels to determine length? pass it with a struct. otherwise, shut up
>>53296459
It is pretty obvious that you don't have a brain, anon. No need to blog about it.
>>53296480
It's OK to be retarded, just don't do it on 4chan.
>>>/tumblr/
>>53296510
oh ok i'm just getting trolled now
>>53296443
what is "the correct tool for the job"
>>53296518
>being literally so retarded you think reality is trolling and saying the most stupid thing remotely conceivable is normal
>>>/reddit/
>>53296549
>what is "the correct tool for the job"
I'm not sure, but I can tell you what "the incorrect tool for the job" is.
C.
>>53296510
>implying 4chan isn't worse than tumblr
>>53296570
kek
but you're wrong
it's C++
>>53296435
nothing about decay there
>>53296471
>other people
yes, the retards that don't know what they're talking about
>extra information is only lost
nothing is lost; the original array is still an array, it didn't lose anything, it didn't "decay" to anything; the expression involving it has pointer type; that's something else that idiots such as yourself can't comprehend
>inb4 pedantry
yes, it's what separates the knowledgeable from the amateurs like you; stick to css programming
>>53296590
Is that literally everyone uses C++ over C when it's not to program for an environment with only C primitives?
>>53296598
cool bud. you can argue semantics all day. good job bud
are you this guy as well?
>>53296152
>>53296624
could you rephrase that? i didn't understand
>>53296627
>hurr durr semantics
read a book, you fucking illiterate shit skin!
>>53296624
english?
>>53296598
are you so retarded as to think that people were arguing that data at rest in a caller got destroyed?
(btw, you can't put words into peoples' mouths then try to engage in a semantics argument about what you thought they meant.)
it's just information as viewed by a callee that's lost, and it's why shit like Heartbleed and the more recent SSL getaddrinfo() bugs come to be.
>C bait threads still get hundreds of (You)'s
>>53294652
>I wanna have nice features across the board, but I don't wanna go through the trouble of figuring out how to make them work stably on a bare metal environment where I don't even have access to a standard library, and I have no idea what the overhead would be
Go away, you're either trolling or buttmad 'cause we can find jobs and you can't.
Stay rectally shattered.
>>53296598
> get told, stays mad
topkek, buddy.
if you can't handle people saying mean things about your favorite language, you probably aren't tough enough to hang around a board even as retarded as /g/.
maybe go to /v/ and try for an even lower audience?
>>53296718
>data at rest
no such thing
>in a caller got destroyed
nope; didn't argue something that doesn't exist
>information as viewed by a callee that's lost
the callee didn't lose anything because it didn't have it in the first place, stop being an idiot
>shit like Heartbleed
sloppy programming, not validating your input is a problem in any language, but cargo-culting retards like you get their knowledge from click-bait article titles
>>53296782
C is the best!
>>53296858
your ass will drip blood for a long time after being rekt by such a big dick
>aren't tough enough
fite me irl, fgt!
>>53296867
C breeds sloppy programming because its type system is so shitty.
Are you surprised that buffer management bugs exist when functions can't return arrays or even accept them without decaying them into pointers?
The language could have been VASTLY better with a very small number of changes, and all your crying can't change the truth.
Stay mad, neckbeard.
>>53296858
>people saying uninformed things
ftfy
>>53296907
> people point out legit criticisms
> become CIDF because they don't use my preferred terminology, don't actually defend the faulty semantics.
kek
>>53296350
>Then none of the C string functions would work with your format, and as a result you'll have to rewrite the entire C standard library.
Actually it wouldn't be a bad "interim" solution.
You could fake real array types with structs containing pointers and a size/length field, and build all the functions of the standard library around that.
But really, we need a C substitute.
>>53296905
>breeds sloppy programming
nah, it's just that the average programmer is shit; you'll be shit with any language but some of them will try very hard to protect you from your stupidity; C doesn't give a fuck about retards like you
>functions can't return arrays
how retarded can you be to want to do that?
>without decaying them
no such thing
>VASTLY better with a very small number of changes
nothing is stopping you to use Go, the "new systems programming language"; oh, performance is shit and you can't actually do systems programming? you don't say!
>all your crying
not the one crying, it's html shits such as yourself that can't comprehend a simple language
>stay mad
why would I be mad when I'm clearly better than you at every single thing? I fell pretty good :^)
>>53296952
>You could fake real array types with structs containing pointers and a size/length field, and build all the functions of the standard library around that.
yep this is what C++ does and is why std::sort is twice as fast as qsort.
Why c++ doesn't have garbage collector?
Becuase there would be nothing left.
TOP KEKS
>>53296996
>>without decaying them
>no such thing
what is it that you've been trying to tell the whole thread for 200+ posts about decayed pointers. what is your point?
>>53296939
>people point out legit criticisms
more like pointing out their ignorance
>my preferred terminology
it's called a standard, you should get acquainted with it instead of talking about stuff you don't understand
>>53297003
>std::sort is twice as fast as qsort
bwahahahahaha
>>53297055
>>fact
>bwahahahahaha
Cfags everybody!
>>53297023
>what is it that you've been trying to tell
>decayed pointers
that they don't exist, how fucking handicapped can you be?
