/tech/ - Technology★

Nothing would boot if we didn't have assembly.

Why is Ada such a meme outside of serious Computer Engineering?

>>953155 (OP)

how into C?

>>953157

Ada is a meme because it was so comically verbose and asinine that even the government found it too expensive to use.

>>953156

But why write assembler directly when for the most part your compiler can generate that for multiple architectures from a single source? Additionaly writing asm directly for some risc architectures is just not that usefull since they were designed with HLL in mind.

>>953155 (OP)

Looks like there's a lot of things to rewrite in Rust!

>>953173

Did you write your compiler?

>>953176

No, since I am quite content with the output produced by clang. What's your point?

>>953183

Just asking a question. Why are you getting defensive?

>>953184

I feared for a pointless discussion to erupt about how you could only trust your compiler's output if you have not written it yourself.

>>953186

Clang huh? What's its advantages over gcc?

>>953163

I found it to be one of the most sane languages I've ever used. It is a big language, but unlike C++ which has disparate features added randomly, Ada works in a coherent whole.

>>953196

you get to take extended multi-hour breaks and heat your house with cpu while it takes 50 times longer to compile.

>>953196

I kinda got used to using clang for development builds because of better error messages und doing production builds in gcc. Although this gap seems to close with every new version.

>>953198

Those days are over and were mostly due to clang/llvm not doing all the optimizations gcc was performing. Now both take quite long to compile bigger projects.

>>953163

But, the verbosity doesn't make it unreadable; unlike Java (and other verbose languages).

>>953163

Wasn't also named by the StingyJeWs?

>>953196

The sensation of self-defeat as you replace a Free toolchain with one that was funded specifically to get the GPL out of tivoized platforms.

>>953196

Not intentionally gimped by a narcissist, foot-scum-eating ideologue, for one.

>>953314

>>953316

Appreciate it anons. This makes it easy to choose which is the better compiler.

>>953323

It's not like you're going to write anything with either.

>>953196

They are both terrible. TCC is also not perfect but at least it takes 10x less time to compile things.

>>953327

TCC is a joke, it's intended for small embedded tasks.

>>953163

Lol, for serious embedded projects like the government/military does, the total LOC produced per hour is like 3 max if you count all hours spend on the cycle. So including inital architecture, code reviews, all the way through to the final test.

I highly doubt that having to type "procedure foo(" instead of "void foo{" was the deciding factor.

>>953197

>It is a big language

Uuuuuuu

>>953197

>unlike C++ which has disparate features added randomly,

Which complaints do you have specifically?

>>953202

>those days are over

Damn it.

C accidentally stumbled into it's position. Historical shit, not quality. Not using C++ for large systems-tier projects in current year is the height of retarded.

>>953178

Something still in use is not equal to something that was in use but has been replaced

Yay, hooray for encouraging lots of bugs. Could've written OS in Ada or something that doesn't totally suck. Hell even Pascal is better. C is the niggest.

>>953489

I heard that C++ is designed. Is that true?

>>953489

Do you enjoy the smell after you talk out of your ass?

>>953546

Do it faggot

C++ AMP does parallel

>Let's run through this. You sit down at your computer. It's running an OS with a kernel with 17,039,677 lines of code. It also has a set of userland utilities with at least 90,638 lines for "core" utilities with another 8,906 for grep and more lines for other "tools", not including libraries like the 1,275,346 line glibc. You open your browser. That browser is written at least partially in 18,824,770 or 36,890,152 lines. You type in a URL and hit enter. That connects to DNS servers to resolve the human-friendly name you typed into an IP address. The most common DNS server is BIND, which is 607,504 lines of code. Those IP addresses are most likely dynamically assigned with DHCP. ISC DHCPD is definitely more than the 1,376 lines of code Open Hub says it is since some files like tree.c are already much larger than that by themselves. I hear some prefer DNSmasq for these tasks. That is 32,314 lines. The web server you're connecting to responds to the request and gives you the page. That web server is running either apache httpd or nginx, which are 1,455,817 and 202,998 lines, respectively. Later on, you go to check your email. Your email client is buggy and bloated.

>How does this make you feel?

It sucks. C requires much more code than other languages and has more bugs per line. That's because basic programming tasks like strings and memory allocation are extremely complicated, slow, and bug prone in C. Anything more sophisticated than slow and buggy strings and some "UNIX backwards compatible" floating point math functions aren't even provided by C, so everyone has to reinvent them from scratch. How much of that code is from memory allocators and garbage collectors because malloc sucks?

The ISC dhcpd allocator alloc.c is a good example of how unproductive C is. It has its own allocating and freeing and its own implementation of strings.

https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=common/alloc.c;h=47609bbc022378b8a291823a7c2c38dfc50e5815;hb=b1ed27b95152c128d735eb36c42cc5c35e001ae2

Everything in C sucks so badly that even with the meager functionality C does include, reinventing your own saves time and increases speed and reliability compared to using the broken bullshit that comes with it. Maybe that's why C weenies think C is productive. Instead of wondering why C strings are so bad that every major program has to reinvent strings, they think C is a great language because making their own strings takes less time than using string.h properly. I also completely left out all the GUI software and libraries other than glibc that need to be present for the browsers and other bloatware to run.

https://www.openhub.net/p/linux/analyses/latest/languages_summary

https://www.openhub.net/p/coreutils/analyses/latest/languages_summary

https://www.openhub.net/p/grep/analyses/latest/languages_summary

https://www.openhub.net/p/glibc/analyses/latest/languages_summary

https://www.openhub.net/p/chrome/analyses/latest/languages_summary

https://www.openhub.net/p/firefox/analyses/latest/languages_summary

https://www.openhub.net/p/bind/analyses/latest/languages_summary

https://www.openhub.net/p/dhcpd/analyses/latest/languages_summary https://source.isc.org/git/dhcp.git

https://www.openhub.net/p/dnsmasq/analyses/latest/languages_summary

https://www.openhub.net/p/apache/analyses/latest/languages_summary

https://www.openhub.net/p/nginx/analyses/latest/languages_summary

> There's nothing wrong with C as it was originally 
> designed,
> ...

bullshite.

Since when is it acceptable for a language to incorporate
two entirely diverse concepts such as setf and cadr into the
same operator (=), the sole semantic distinction being that
if you mean cadr and not setf, you have to bracket your
variable with the characters that are used to represent
swearing in cartoons?  Or do you have to do that if you mean
setf, not cadr?  Sigh.

Wouldn't hurt to have an error handling hook, real memory
allocation (and garbage collection) routines, real data
types with machine independent sizes (and string data types
that don't barf if you have a NUL in them), reasonable
equality testing for all types of variables without having
to call some heinous library routine like strncmp,
and... and... and...  Sheesh.

I've always loved the "elevator controller" paradigm,
because C is well suited to programming embedded controllers
and not much else.  Not that I'd knowingly risk my life in
an elevator that was controlled by a program written in C,
mind you...

>>953608

> has more bugs per line

Yep. x += y; has so many bugs in it.

>>953612

That line does contain a bug because it could overflow. C has no way to detect that overflow has occurred. I think it makes sense to trap when unsigned arithmetic overflows too, but C weenies use "unsigned" to mean "won't trap" instead of its real purpose, to represent numbers that can't be negative. Adding 100 and causing a number to overflow and become less than 100 is just as bad as adding 100 and causing a number to become negative.

It would be a good thing if hardware designers would
remember that the ANSI C standard provides _two_ forms of
"integer" arithmetic: 'unsigned' arithmetic which must wrap
around, and 'signed' arithmetic which MAY TRAP (or wrap, or
make demons fly out of your nose).  "Portable C
programmers", know that they CANNOT rely on integer
arithmetic _not_ trapping, and they know (if they have done
their homework) that there are commercially significant
machines where C integer overflow _is_ trapped, so they
would rather the Alpha trapped so that they could use the
Alpha as a porting base.

>>953618

Oh no. I don't know how to check the carry flag? The post.

>>953608

>ISC

Bad programmers write bad code regardless of language. Embedded folks use dnsmask to provide DHCP because despite the limited scope it's much higher quality and ironically supports more features of the protocol.

>C strings

>C memory allocation

>slow

Sounds like you're just a bad programmer.

>>953623

>I don't know that you can't portably check the carry flag in C, the post

>>953635

>I don't know what the asm keyword is for in C.

>>953618

There's nothing wrong with intentionally overflowing an unsigned value. It's a heavily used technique for speed. Maybe this is just a level of software engineering you're not comfortable with and should go back to webdev and let others write the libraries you depend on?

>>953637

>asm

not C

>>953637

>I think I can write portable assembly

>I think all architectures have a carry flag

>>953666

Who said anything about portability?

>>953641

asm keyword is C

>>953667

<I don't know that you can't portably check the carry flag in C

>I don't know what the asm keyword is for in C.

>>953667

The asm keyword is not C. It's listed as a common extension in the standard as a warning to compiler implementations and is not required.

I'm no C expert but wouldnt you just be able to do sth like (not perfect but works in most cases):

int finalx = x+y;
if(finalx<x){
  x+=y;
}else{
  //just an example
  x=INT_MAX;
}

Also it's the task of the programmer to see where such overflows could occur which are critical to correct program behavior.

Why are we even having this thread? Shouting that C is the foundation of everything, because it's closest to how the machine works without being bound to a specific architecture, is like implying there is room for denying it.

>>953678

fug

*finalx>x

>>953668

Who said anything about portability?

>>953670

asm keyword is C

>>953678

anything that can be compiled could be the foundation. C is popular because of unix.

>>953683

No, the foundation has to be the one with the smallest common denominator otherwise everything will run like fucking Java.

>but muuhhhhhhhh dats miiy dreeeem

It is because you have yet to experience it. To our luck Java faggots are unproductive as fuck and rarely write anything bigger than Hello World programs. The only Java program I use is JDownloader2 and that's it.

How do you address single bits also called booleans in memory without C struct bitfields?

Which language would you use for the task?

>>953683

Now you pretend you didn't read it already because you have no arguments anymore.

>>953696

You wanna argue about Java being shit go ahead.

You can't address single bits in modern architecture anyway so idk what you are talking about.

>>953638

>There's nothing wrong with intentionally overflowing an unsigned value. It's a heavily used technique for speed.

What does a large number suddenly becoming much smaller have to do with speed? If you go to download a big file and the size wraps around to 300 bytes because of an unsigned overflow, it would "download" faster, but that would suck.

>Maybe this is just a level of software engineering you're not comfortable with and should go back to webdev and let others write the libraries you depend on?

I'm not comfortable with 17 million line kernels and 30 million line browsers. What sucks about UNIX culture is that they measure value by the amount of code instead of by functionality, quality, and usefulness. That's probably why they prefer monolithic monstrosities like Linux over microkernels where people can write drivers in whatever language they want.

>>953678

>Also it's the task of the programmer to see where such overflows could occur which are critical to correct program behavior.

C doesn't provide any way to detect integer overflow at all. Assembly is not C and C is not assembly.

>Why are we even having this thread? Shouting that C is the foundation of everything, because it's closest to how the machine works without being bound to a specific architecture, is like implying there is room for denying it.

You're brainwashed. Some parts of C are based on whatever the PDP-11 did, like the pointers and flat memory model, but C is not closest to how any machine works. That's AT&T marketing, not reality. AT&T shills knew people criticized C for not having good arrays, strings, numbers, control structures, memory management, linking, macros, and so on, so they made up this bullshit that C is actually portable assembly, so all of its mistakes are the hardware's fault. Every single problem with C is blamed on hardware and programmers who use the language, instead of the AT&T employees responsible. AT&T ran into the same problem, but since they didn't care about quality, they didn't have a reason to complain about their own bugs and blamed the users for using the "tools" the wrong way.

>>953688

>No, the foundation has to be the one with the smallest common denominator otherwise everything will run like fucking Java.

Java defines all overflows as wrapping around. This doesn't have anything to do with why Java is slow.

>How do you address single bits also called booleans in memory without C struct bitfields?

>Which language would you use for the task?

PL/I has bit strings which have the properties of strings and you can also say how many bits a number is. This is what Multics did since before C and UNIX existed.

http://multicians.org/mtbs/mtb692.html

dcl 1 encoded_access_op       aligned based,
      2 audit_type,
        3 object_type         fixed bin (4) uns unal,
        3 access_type         fixed bin (2) uns unal,
      2 operation_index       fixed bin (12) uns unal,
      2 detailed_operation    fixed bin (18) uns unal;

You have obviously been brainwashed.  You can't tell working
software from broken software.  If you don't have some
horror story, or some misdesign to point out, KEEP YOUR
POSTS OFF THIS LIST!!  Kapeesh?  We don't want to hear your
confused blathering.  Go bleat with the rest of the sheep in
New Jersey.

    Of course, used to the usual unix weenie response of
"no, the tool's not broken, it was user error" the poor user
sadly (and incorrectly) concluded that it was human error,
not unix braindamage, which led to his travails.

>>953730

>What does a large number suddenly becoming much smaller have to do with speed?

Power-of-two ringbuffer indexes work via small registers or ANDing off the top bits of a larger register and letting the remaining bits overflow to loop. The webdev alternative is to do like,

if (index >= size) index = 0;

but this involves a conditional and divergent codepaths. It's significantly slower, and in some cases like in a CUDA kernel will completely destroy performance.

Various other algorithms rely on adding large primes to indexes that wrap to effect a 'random' walk of a buffer, and some encryption algorithms do similar with the inverse of the golden ratio as part of the key schedule.

This is a level of software design that you'll probably never be comfortable with, and that's fine. Stay away.

>>953730

>What sucks about UNIX culture is that they measure value by the amount of code instead of by functionality, quality, and usefulness.

They do? Last I checked, Linus Torvalds was very uncomfortable with his kernel's size, mainstream web browsers are hated as bloated pieces of shit, and the suckless movement is making some great software with very minimal codebases.

>muh microkernels

Nice in theory, but they've had a mixed track record aside from SeL4 and QNX.

>C is not closest to how any machine works

That's part of its appeal: it doesn't rely on architecture-specific features and works on practically anything, but it's still vaguely low level enough that reasoning about performance and underlying hardware features/quirks is fairly easy. Sure, the langauge definitely has its flaws but it's popular in embedded circles and almost everywhere else for a reason.

>>953155 (OP)

>You sit down at your computer.

With a CPU running an opaque hypervisor coded in C that's vulnerable to remote exploits

>It's running an OS with a kernel written in C.

Which is buggy and vulnerable to remote exploits

>It also has a set of userland utilities written in C.

Which are buggy and vulnerable to remote exploits

>You open your browser. That browser is written at least partially in C.

And buggy and vulnerable to remote exploits

>You type in a URL and hit enter. That connects to DNS servers to resolve the human-friendly name you typed into an IP address.

Or to an eavesdropper that is able to run remote exploits because your C-based network stack is buggy and vulnerable to remote exploits

>The most common DNS server is BIND, which is writtten in C.

It's also the most buggy and exploited

>Those IP addresses are most likely dynamically assigned with DHCP. ISC DHCPD is written in C.

Which is exploitable

>I hear some prefer DNSmasq for these tasks. That is also written in C.

Which is also exploitable

>The web server you're connecting to responds to the request and gives you the page.

Either that, or the full list of the emails and passwords in their database because their predominantly C-based LAMP stack is buggy and vulnerable to remote exploits

>That web server is running either apache httpd or nginx, which are both in C.

And thus is buggy and vulnerable to remote exploits

>Later on, you go to check your email. Your email client is written either partially or completely in C.

Good thing I don't use a client written in C, that would be buggy and vulnerable to remote exploits

>You most likely connect to an external server that stores your mail. That server needs special software to do its job, and there are often serveral options.

Your spell checker is probably buggy and vulnerable to remote exploits

>To mention a few, Postfix is in C, Sendmail is in C, Exim is in C, OpenSMTPD is in C, and Dovecot is in C.

All had to be patched the hell out of to prevent them from being buggy and full of remote exploits

>What if you want to transfer a file at some point?

I'd do it with a secure protoco-

>FTP?

Oh, you're serious. Let me laugh even harder.

>The standard FTP/SFTP clients are in C. vsftpd is in C. pureftpd is in C. profptd is in C.

Which are buggy and vulnerable to remote exploits

>SMB? Samba is (at least in part) in C.

That must be the part that's buggy and vulnerable to remote exploits.

>Need to connect to something over secure shell? ssh client and daemon are in C.

Which are ancient but still need to be patched every odd week because they're buggy and vulnerable to remote exploits.

tl;dr while I'm impressed by the elegance and simplicity of sand castle design, I think there's much more of a future for concrete in the construction industry.

>>953757

C's weaknesses are now advantages. The enemy isn't outside the gates anymore, it's inside and is pushing you out. If you lock everything down now, you'll soon find you've helped lock yourself out of your own devices with Google and Microsoft spying on you from the safety of their flawlessly secure hypervisors.

>>953757

>using Google or Microsoft software in the first place

>>953761

You won't have a choice. They'll be running above your Linux distro, like Minix does today.

>>953766

>You wouldn't have a choice

Bullshit, I can buy whatever hardware I please and I avoid (((Intel))) like the plague.

>>953155 (OP)

C is great for systems programming, but shit for applications. Not sure what your points is.

>>953155 (OP)

>You sit down at your computer. It's running an OS with a kernel written in C.

Not if I use Haiku.

>It also has a set of userland utilities written in C.

True only for Unix-like systems. Mac OS, while it does include FreeBSD stuff written in C under the hood, has produced most of its "userland" in Obj-C. Windows has produced most of its "userland" in C++ and C#.

>You open your browser. That browser is written at least partially in C.

Not really sure how that's relevant. Most of, say, Firefox, is written in C++. Yeah, there's some C. It's being swallowed by Rust code...

>DNS daemons are written in C

Sure.

>That web server is running either apache httpd or nginx, which are both in C.

I hope you know that Apache and nginx aren't the only web servers. It's true, however, that a lot of web servers are written in C. People looking for performance like C. Of course, people looking for vulnerabilities in networking software also like C. So, there's that.

>Bunch of network daemons use C

Yeah, yeah, same as above.

>ssh client and daemon are in C.

OpenSSH is in C. There are many ssh v2 clients and daemons. Some are in C. Some aren't.

>How does this make you feel?

Indifferent.

>>953754

>muh microkernels

>Nice in theory, but they've had a mixed track record aside from Minix and QNX.

ftfy. seL4 is an interesting research kernel with some potential, but that's all so far, in spite of morons constantly memeing it here.

Supposedly Plan 9's take on C is pretty good, although I haven't looked into it much aside from its threading library and Go-style #include restrictions.

>>953688

>How do you address single bits also called booleans in memory without C struct bitfields?

>Muh only C can access muh bits...

See below how to do something like that in a language that is not c. Example uses an array, but of course you can extend it no records, records with arrays in them, arrays of the same record type.

with ada.Text_IO; use ada.Text_IO;
procedure Main is

   type Bit is range 0 .. 1 with size => 1;
   type Byte is range 0 .. 255 with size => 8;
   type Op_Type is (Not_A_Faggot, Faggot) with size => 1;

   type Op_List is array (1 .. 8) of Op_Type
     with Pack, Size => 8;

   foo : Byte := 2#1111_1111#;

   This_Board : Op_List with Address => foo'Address;
begin

   for op of This_Board loop
      put(Op_Type'Image(op));
   end loop;
end Main;
--Prints FAGGOTFAGGOTFAGGOTFAGGOTFAGGOTFAGGOTFAGGOTFAGGOT as expected

>>953155 (OP)

>OS with a kernel written in C

My kernel is written in rust.

>>953883

Wow, not everyday see a person who knows Ada Language.

Do you professional code on Ada or it is just a hobby? Is it worth to learn it for interesting job (military or something else)?

>>953883

Sry, expected just the UNIX hater with random quotes from email archives in the code box shilling something like LISP or Java or whatever memelang comes into his mind.

Also >>953937

>>953937

Hobby for now, still learning how to use it properly. If you seek the easy road to employment just go for c/c++.

I think however, that Ada, or Spark, is a much better way to program embedded systems than C/C++.

Somewhat related, if you look at Structured text used for PLC programming, the language is derived from the Pascal/Algol family, same as Ada. I think they did that for a reason.

>>953174

Why not JavaScript, you low-level luddite?

>>953327

It's literally slower than GCC at -O0. And produces slower code.

>>954087

>understanding how a machine works internally is being a luddite

>>953157

I had a teacher who used to be in the military and worked at a nuclear control center. He unironically says Ada is his favorite language and he loves it.

>>953635

inline bool carry(unsigned x, unsigned y)
{
	return x+y < x;
}

every compiler worth its salt will recognise this idiom if optimisation is turned on and use the carry flag you retard

>>953766

>tfw in 20 years Intel will probably run some stripped-down Windows in their ME instead of Minix

>>954092

OMG it's $CURRENT_YEAR, I can't even...

>>954122

>tfw I can actually imagine that looking at the second Windows installation for repair

Anon you're making me afraid.

>>953155 (OP)

I love how you list a bunch of useless tripe like DNS, email, and FTP as applications of C. The only reason I still use C is because I haven't switched out my kernel yet.

>>953163

No you retarded nigger. C is popular because it's popular, Ada is not popular because it's not popular. No other reason. Ada is not any more verbose than C (conforming C, or at least portable C, not your chicken scratch)

>>953612

even as a trolling attempt this is fucking retarded

>>953637

HAHAHAHA

He thinks he's elite because he knows about the asm keyword, but he isn't even aware of the concept of portability in C.

>>954208

Ada's verbosity and high cost to develop in was a fax machine meme for at least a decade, kiddo. While Ada 2005 tried to address that, 2005 was long after everyone had chosen to deprecate Ada.

>>954214

Who said anything about portability?

>>954211

No.

>>954114

Once again, the carry flag cannot be checked portably. For example, x86 and ARM differ on when the carry flag should be set. Unsigned addition is the same but unsigned subtraction differs.

>>954228

It's literally the inverse on ARM of what it would be on x86. Who the fuck cares if the code is portable and compiles into optimal instructions. Some ISAs don't have a carry flag at all, anyway.

>>954274

>Who the fuck cares if the code is portable and compiles into optimal instructions

Actual programmers.

>>954277

Actual programmers know the arch's they will be programming for and take the time to write source that implements the necessary precautions for those arch's and get the job done without complaining.

>>954293

No, actual programmers write portable code so it continues to work on new hardware. Would be a sad tale for RISC-V if all the open sores didn't work on it.

>>954299

Who gives a shit about a new arch that doesn't even have a compiler written for it? Why should someone write for an arch that didn't exist when they wrote the source? You are moving the goal posts.

>>954091

bullshit

#CFLAGS='-O0 -std=c99 -pedantic'
env CC=gcc time make -s
real 5.950000
user 5.470000
sys 0.430000
make clean
env CC=tcc time make -s
real 1.610000
user 1.440000
sys 0.150000

>muh faster binary

I prefer working binaries to fast ones. Both gcc and clang perform unsafe optimizations in the race to the bottom to produce the fastest binaries.

>>954219

yeah, a meme among a bunch of "software engineers" who see a line of Ada and be like "XDDD what is this zomg it's not like <insert my lang here>!!!!!!"

>>954293

actual "programmers" test something once on the machine they're running on and ship it. they aren't even aware that a concept like portability exists in C. and why should they be? the schools don't even teach this either

>>954221

you can't check carry in C you oblivious shithead. and the only time you'd bother to do it in assembly is in a highly optimized piece of code, not every single time you do arithemetic.

now this leads to the mystery of how a retard like you programs C? if you have assembly shit everywhere, how will you ever run it on anything other than your x86 macbook? why even program C in this case when you can just program assembly? i guess it's faster to scribble down most of the code in C, but then this leads to the next question, how are you dealing with UB? do you even know what that is? probably not since you don't even seem to understand portability beyond for the sake of arguing that it's not needed

>>954303

refer to the disaster of the x86 32-64-bit transition

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer

Th-thank you, C.

>>954313

I am not arguing for portability. Haven't and won't. If a programmer wants his program to run on multiple arch's, he knows the arch's he wants to run them on and writes appropriate source for them. You think java compilers or rust compilers or lisp interpreters aren't susceptible to programming errors like C or assembly has?

>>954318

Java compilers have errors but that shouldn't be hard to fix. The point of using Java is so that the programmer targets only the JVM and the JVM does the hard work of translating to a specific architecture.

>>954321

Someone has to write the JVM for the specific arch.

>>953155 (OP)

>That connects to DNS servers to resolve the human-friendly name you typed into an IP address. The most common DNS server is BIND, which is writtten in C.

All that traffic goes over a switching network written in COBOL. Checkmate C-theist.

>>953489

>accidentally stumbled into it's position

>whoops, I accidentally an operating system!

>oopsy, I accidentally a programming language across my whole org

>oh no, I by mistake became the foundation for every other modern language.

>>953608

>it has it's own allocating

If you use java, you're stuck with whatever allocator you get! Therefore, java must be better.

>Since when is it acceptable for a language to incorporate two entirely diverse concepts such as setf and cadr into the same operator (=)

Fuck off lisp fag.

>>954277

Read the code you're responding to once again (you can read code, right?). How is it not portable? It does the exact same thing on every arch. On some arches, it will be optimized, on some it wont, but it always does the same thing

>Actual programmers.

Actual programmers are being paid by a client for a particular architecture. They could make it run on Babbage's analytical machine for all the client cares, but they aren't getting a dime extra for it.

>>954307

which repo is this? I'm sure toy codebases where both tcc and gcc shine exist.

>>954277

Okay, after rereading my previous post I see it could easily be misread. I meant who the fuck cares as long as the code is portable and compiles into optimal instructions. Sorry for the misunderstanding faggot.

>>954307

>Both gcc and clang perform unsafe optimizations

Only if you explicitly enable them.

>>954313

>you can't check carry in C you oblivious shithead

wrong

>>954114

>>954313

>refer to the disaster of the x86 32-64-bit transition

The only disaster I remember was/is on Windows. Leenoox jumped to x86-64 pretty quickly and painlessly.

>>954322

...once. Then all programs ever written for that VM should just run on top of it without modification. At least that's the idea.

>>954345

Once means it's required. You don't really have an argument. Portability is a non-argument between different arch's because it is inherrent to program new compilers to handle them.

>>954343

Now do it for signed integers.

>>954336

>Read the code you're responding to once again

Read the replies again. An example I gave was that unsigned subtraction will not work as expected by the author.

>On some arches, it will be optimized, on some it wont, but it always does the same thing

The post was about portably checking the carry flag, not "always doing the same thing". And for subtraction a portable approach like that trying to infer the carry flag state from a C operation would not give the correct result on either x86 or ARM since they use it differently.

You cannot portably check the carry flag. There might not even be a carry flag.

>>954341

What is -fstrict-aliasing?

>>954386

The sweaty nightmare of programmers who refused for years to fix their shitty code because "works for me, bro".

>>954382

https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow

>>954386

An option that enables non-standard behavior no program should ever rely on?

>>954395

#include <limits.h>
  
void func(signed int si_a, signed int si_b) {
  signed int result; 
  if (si_a > 0) {  /* si_a is positive */
    if (si_b > 0) {  /* si_a and si_b are positive */
      if (si_a > (INT_MAX / si_b)) {
        /* Handle error */
      }
    } else { /* si_a positive, si_b nonpositive */
      if (si_b < (INT_MIN / si_a)) {
        /* Handle error */
      }
    } /* si_a positive, si_b nonpositive */
  } else { /* si_a is nonpositive */
    if (si_b > 0) { /* si_a is nonpositive, si_b is positive */
      if (si_a < (INT_MIN / si_b)) {
        /* Handle error */
      }
    } else { /* si_a and si_b are nonpositive */
      if ( (si_a != 0) && (si_b < (INT_MAX / si_a))) {
        /* Handle error */
      }
    } /* End if si_a and si_b are nonpositive */
  } /* End if si_a is nonpositive */
 
  result = si_a * si_b;
}

What a simple and elegant solution.

>>954462

That's not true at all. Violating strict aliasing is UB, -fstrict-aliasing just allows optimizations that assume you aren't doing stupid things like depending on UB.

Again, it does not enable any non-standard behavior at all. Aliasing behavior is undefined or implementation-defined by default.

>>954478

Bah, misread that. -fstrict-aliasing is the default when optimisation is on. I meant -fno-strict-aliasing enables non-standard behavior. I really need to get some sleep.

>>954343

Yes, if you rely on some specific compiler to convert your code into a carry check. Meanwhile, the concept of carry probably doesn't exist anywhere at all in formal C.

>>954344

that's because shit like apache is just a bunch of nothing code, and you're wrong about the rest of the linux desktop which to this day still segfaults every 5 minutes in all of gnome,kde,xfce, etc

>>954519

>you're wrong about the rest of the linux desktop which to this day still segfaults every 5 minutes in all of gnome,kde,xfce

I do all my work on a 64 bit Linux desktop running GNOME and haven't had it crash in years. Maybe the problem is you.

>>954538

>using GNOME beyond the 2000s

LOL

>>954538

>Maybe the problem is you.

and this is precisely how you implement the very worst piece of trash software in existence, you just pretend every problem is the way people are using it

>>954547

oh wow fuck it, like we're talking about GNOME here, literally every GTK program in exists spews out "WARNING CRITICAL ERROR BLAH BLAH" to stdout for the duration of their run. if you can't understand how such leads to segfaylts, then you probably shouldn't be on this board

>>954547

I don't see outpourings of complaints about these every 5 minute crashes from people using Ubuntu LTS or Debian stable. So yeah, I think the problem is you. You're probably on some riced version of gentoo with custom flags.

>>954519

>>954538

>>954547

The major desktops are very stable themselves, if you get constant crashes the most common culprit is dodgy video drivers.

>>954519

>Meanwhile, the concept of carry probably doesn't exist anywhere at all in formal C.

Well no shit Sherlock. Different ISAs use the concept differently (or not at all). There is no way to specify it in a portable way.

What *is* possible is to write portable code in a way that makes it easy for the compiler to use such ISA features whenever they're available and fall back to software emulation when they're not. In each case you get efficient, close to optimal code without having to write unportable assembly by hand.

>>954462

s/enables/disables/ obviously

>>954468

Every processor made for over 50 years supports doing something on signed overflow, yet here we are coding around the hardware because we continue to use a piece of shit language.

>>954382

It works for signed integers too. Or did you mean the overflow flag? That's a different thing - and available on even fewer ISAs.

>>954561

>something

>blowing up an exception to crash the program

>>954564

< I'd rather the program gave me a wrong answer than fail because it cannot give me a right one.

>>954564

I'm rather amazed that you defend this behavior, given that it is inconsistent: if you try to divide by zero, your program dies. Everyone has the sense that division by zero is a program killing operation, but heaven forbid similar errors of program logic cause similar effects.

>>954567

Divide by zero is handled for free as it causes a fault. Signed overflow is not as it's not an error at the assembly level on any processor I know of. So it's up to the language to decide if it wants to waste time second-guessing every operation you perform, and a low level language like C certainly should not. As it's fairly expensive, even Java doesn't check overflow.

>>954579

Why do you keep saying C is low-level? Only assembly and binary instructions are low level programming. Everything else is high level.

>>954582

C is a the closest we have to a low level portable assembly. With some jiggling, I can get it to portably generate the exact assembly code I want in almost every case.

>>954582

>low-levelness is a binary trait

>there is no gradation from low to high abstraction levels

>hurr durr I suck cocks

>>954583

It's not assembly. It doesn't look like it. It doesn't behave like it. It's a high level language that was designed to allow workers at Bell Labs to make more efficient use of their time.

>>954584

I don't care about your obfuscated """abstractions""". That shit does not define the strata of programming languages. You are either writing the hardware directly (low-level) or you are using some kind of compiler or interpreter to handle talking to the hardware for you (high-level). Only assembly and binary instructions fall into the first category, everything else is in the latter. Go fuck yourself.

>>954563

The code in >>954114 doesn't necessarily work as intended if x was signed. Because signed integer overflow is undefined, x+y can never be smaller than x for any unsigned y. Thus this comparison may be optimized to always return false. If y was signed too, the comparison might be optimized to return the sign of y (true for non-negative, false for negative).

>>954590

false for non-negative, true for negative

>>954585

>It doesn't look like it. It doesn't behave like it.

Yes it does. It's very closely mapped to the capabilities of the machine which is why it's used at a low level.

And tbqh if the compiler detects undefined behavior, it absolutely should return random results at runtime.

>>954590

You were supposed to cast the signed inputs to unsigned function arguments, then everything is 100% well defined. You do understand that carry is not overflow, right?

>>954594

Somebody should make a DeathStation 9000 emulator and GCC backend already.

>>954594

Have fun spending your life debugging.

>>954598

That is 100% undefined as C doesn't assume two's compliment.

>>954598

>You were supposed to cast the signed inputs to unsigned function arguments, then everything is 100% well defined.

Missed the point.

>You do understand that carry is not overflow, right?

Depends on the architecture. :&)

>>954605

Surprisingly it's not undefined, but the result becomes pretty much useless.

>>954602

#include <stdio.h>
#include <stdbool.h>

int main()
{
    bool a;
    if (a) puts("true");
    if (!a) puts("false");
    return 0;
}

gcc generates code that outputs true and false. clang's code writes true or false, runtime-randomly.

>>954611

That's why we use valgrind. It was hell debugging before that. I used to use Purify on SunOS but as we didn't intend to actually release on SunOS we were maintaining a port just to be able to use that tool.

Lots of talk but no disassembly of >>954114 so far. Absolute state of /tech/, you lazy fucks.

gcc and clang with -O2 add x and y and return the carry flag:

add %edi,%esi
setb %al
retq

For signed x and y, gcc with -O2 adds x and y and compares the result to x:

add %edi,%esi
cmp %edi,%esi
setl %al
retq

For signed x and y, clang with -O2 shifts y 31 bit to the right and returns it, i.e. it returns the sign of y:

shr $0x1f,%esi
mov %esi,%eax
retq

>>954622

>x86 disassembly

>when the issue was portability

>bothering testing signed overflow when it's UB

You sure showed us.

>>954625

Missed the point, again. My post demonstrates possible consequences of UB. The reason UB exists is portability.

>>954626

>possible consequences

Who cares, it's UB. No need to look any further unless you're a compiler historian.

In the interest of full disclosure, I'll also point out that C is also the source of the majority of the world's software security holes.

I work in C because there's a big project some big brain made that I like to play with and add little features to, otherwise I would never touch this shit.

I could code all this string manipulation shit people are complaining about if I wanted to spend half an hour doing it, but it's much easier to just copy-paste code from elsewhere, and spend my time working on the actual parts that are interesting.

If you write your own C method to replace substrings with others, bashing your head against the wall, you're a fucking idiot.

>>954630

PHP has done more damage imo.

>>954641

PHP has become pretty good in the recent years the majority of its programmers hasn't

>>954554

The last time I used Fedora all I saw was assertion errors in the stdout of every GTK program, so no. I do use Gentoo but it shouldn't matter much, and there isn't any sort of ricing to speak about. What do you think, they're crashing because I don't have metacity? The only reason it would crash on Gentoo is because the software is incompatible with the set of dependencies Gentoo has, which means it has undocumented incompatabilities. For instance pcmanfm might crash with some version of udev which Ubuntu devs worked around by bruteforcing until they found a verison of udev that worked or just made their own patch.

>>954555

I see tons of crashes that have absolutely nothing to do with video drivers. For instance in pcmanfm (a file browser, some of the only GTK bullshit I've used lately), setting a file filter while it loads the list of files in a folder, will crash it. But this case probably has nothing to do with the 32-64-bit transition.

>>954558

But I could just use Haskell then since I know it will compile to some good C if I write it a certain way

>>954584

C is a high level language and you're a retard level if you don't understand this. Go read the C99 spec and explain how any of that has anything to do with hardware other than so happening be compileable to mostly efficient assembly code.

>>954622

For the love of God, use -masm=intel when you make gcc generate x86 assembly listings. The AT&T syntax used by default is homosexual to a horrendous degree.

>>954579

>So it's up to the language to decide if it wants to waste time second-guessing every operation you perform, and a low level language like C certainly should not.

No, a language shouldn't second-guess every operation in production code. However, C doesn't do so in all code generated, and its programmers rely on unspecified behavior, complaining that the bullshit they do isn't really wrong and the compilers are wrong when they do valid transformations to their bullshit code. The biggest problem with C is the programmer culture of garbage is good

>>954675

Your entire argument is the complaint that you don't like the C programming community?

>>954683

Eh.... More or less. It's the complaint that the language is shit because the community is shit, who reinforce that the language is shit.

Once you have debugged code, you shouldn't need overflow checks. That should have been resolved during development. But the language doesn't distinguish between this development phase and a production phase. NDEBUG? Garbage. The language doesn't give the tools to write better code, and the community scoffs at better code producing practices. There are good reasons to ignore signed integer overflow, but 99% of developers will never run into them, but 100% of C developers insist on not doing anything so that they can feellike they are in that 1%, like a liberal feels like supporting socialism is actual charity.

Really, I understand that one of the major problems is that no one has figured out how to properly notate the code for doing checks. Though, even if they were present in C, the community would never use them (or use them to indicate that it will never happen) because they are garbage programmers. Mostly, it's because writing good code is hard, because there are so many failure states, that most people just try to write code that works on the golden path. And the pajeet-teir C programmers (which includes Ken Thompson and Dennis Ritchie) are just trying to keep things working.

>>954675

>The biggest problem with C is the programmer culture of garbage is good

The irony being that you're posting this via several hundred million lines of extremely stable C and C++ while still personally struggling with writing a lisp text editor.

>>954696

The irony is that I'm almost exclusively a C++ developer. Java and C are my second languages. The fact that the kind of overflows that I am complaining about never occur in the production versions of the software I use (and I'm posting from FaggyFox, so it's full of soy Rust) doesn't mean that the language should ignore them at all times. When I run a problematic input file in the debugger, trapping on overflow should be my indication of why shit went south, not something that I should ignore to find a deeper problem. I have this faggot coworker who uses asserts on user input. That's the kind of bullshit faggot asshole C developer community that I'm talking about. He uses checks that are compiled out of production code on user input. What kind of fucking idiot does this: a C developer. No wonder the program he works on is so full of fucking bugs that my organization has actually thrown away the backlog on four fucking occasions to make it more manageable. And whenever I debug issues in that program, I invariably have to disable numerous assertions to find the actual cause of the problem. I should turn those assertions into throwing exceptions and save myself the trouble, however invariably, it's then my fucking fault that the program no longer accepts that input, even though it was that fucking fucker who broke that behavior. Those fucking users have so much Stockholm syndrome with that fucking POS developer it makes me sick. The fucking point of my rant is this: C developers are either garbage, like my coworker, or are fucking idiots with Stockholm syndrome, like my users.

>>954694

Then stay out of the C community if you don't like it? You seem like a bitch who likes to start shit just to be involved in shit because you consume shit.

>How does this make you feel?

Why does this matter?

If a machine works as intended, my feeling should be part of the logic.

Waiting on OP/respondents to provide a non-ANSI C OS and suite.

If ada is their recommendation, they better source their OS and HTTPc used to make their response here.

e.g.

OpenBSD: ANSI C

HTTPc: lynx: ANSI C

s/should /&n't/

>>954694

>>954699

>prefer C++ over C

>exceptions are good

wew m8

>Once you have debugged code, you shouldn't need overflow checks. That should have been resolved during development.

Because user input can't cause overflows, right?

Talking about programming in a very hormonal manner? You must be a tranny.

>>953155 (OP)

This reads like some edgy kid trying to impress his tech-illiterate friends on Facebook.

>>954707

No. I'm a drama queen because I have to fix your cocksucking piece of shit's code. And make no mistakes: you are all cocksucking pieces of shit. The average C developer sucks so much cock it causes a signed 64bit overflow. And that is my job: to clean up all the cum you leave over everything, because the government decided to use your garbage.

>>954764

>Because user input can't cause overflows, right?

So, you have shitty testers/test data? I test overflow cases before throwing it to testers because I have pride in my work. The code checks for overflow conditions in the shitty C way, because I am paid to write safe C code. I dont' t know about you, you shitty piece of shit. You don't care, do you? Like my motherfucking coworker who only checks user input in debug mode? That's what I fucking thought. You are a shitty developer trying to defend yourself, and your shitty development practices. In fact, the entire software world would be better off if you died and were replace by either niggers or pajeets. That is an objective fact.

>>954764

You know what, you fucking cocksucking piece of garbage? Fucking people like you are why the soyboys using Rust and other garbage languages are making such inroads in programming and making it such a shit environment. Because they actually fucking have pride in the stupid fucking garbage they produce. Unlike you, you fucking cocksucking piece of shit, who doesn't give a goddamn shit about anything. You are the reason soyboys have influence, because their investment in their work is noted, and your fucking shit demeanor is also noted. Who are you going to work with? The piece of shit who believes that the garbage they've made can be improved, or you, the piece of shit who believes that they've made gold even though it's demonstrably garbage? You are a fucking piece of shit and you should kill your self.

>>954790

Terry?

>>954652

my nigga

>>954656

again, by claiming gentoo is unstable you are just admitting that software is shit. the only way a distro can be unstable is because they didn't have enough volunteers to brute force combinations of dependencies to work out the real dependency requirements software failed to list (and therefore said software is shit)

>>954675

yeah one of the biggest problems, the other problem is that C isn't a good language

>>954740

>Waiting on OP/respondents to provide a non-ANSI C OS and suite.

There are plenty that exist and they are all shit just like Linux and probably worse. But that has nothing to do with the language they're written in.

>>954788

>The average C developer sucks so much cock it causes a signed 64bit overflow.

Somebody please cap this and make a banner out of it. Kek.

Is rust an mitnigger languge? I like it, but at the end of the day I feel like I'm just writing C through a very pedantic proxy.

>>953688

>How do you address single bits also called booleans in memory without C struct bitfields?

Are we seriously asking this? C does not do single bit addressing magically.

In any truthy language with proper integers:

bitfield = 0b00100100
address_3 = 0b00000100
return bitwise_and(bitfield, address)

You would need an enum for all bits in the minimum addressable size, or simply bitshift a 1 to the left as many positions you want to address that position. This is probably what C does behind the scenes, because the minimum addressable size in most architectures is 8, not 1. Almost all languages allow for bitwise ops, including many shit languages with floats only, like JavaScript, it's just that only C requires abusing them.

What to do in a non truthy language is left as an exercise to the reader. :^)

>>955201

Rust is a "not get anything done" language. Most desktop programs do not need the amount of reliability Rust forces you to write, just being mostly memory safe, which has been a thing since before C.

>>953173

because SPEEEEEEEEEEEEEED

>>955230

Rust is a language for programs that need to be memory safe and fast, like browsers or generally anything that parses tons of untrusted input. If you just want memory safety you might as well use python or java. In theory it would be ideal for kernel modules, but in practice, despite claiming to be a "systems" language, it's a PITA to write anything other than userspace applications for linux and libraries for other rust software.

>>955201

It's more like a pedantic C++ proxy with a somewhat sane syntax tbh.

>1969

>be developer for Multics

>Bell labs leaves the project, leaving you alone

>make a game for it in your spare time

>costs multiple 1969 dollars to play even once because Multics is a mainframe OS

>decide to port it to a smaller, cheaper machine

>in the process end up remaking lots of Multics, but neutered

>name it Unics for the pun

>get a friend named Dennis

>name mutates to UNIX over time

>Bell labs is interested again and ends up owning UNIX, publishes first version

>Dennis gets crazy idea

>"let's write the OS in a higher level language, in a way that it can be compiled for different machines"

>have to make a language that can do this

>call it C

>>954840

Gentoo is unstable because they're literally an unstable rolling distro. They don't ship bugfixes they ship new versions with new bugs. On top of that, everyone has different compiler flags which expose different bugs, and nodev clueless attempts at hardening that create bugs in bug free software. Bug reports from gentoo users get shitcanned because they're rarely a bug.

>>955330

If your software breaks because of compiler flags that you didn't test, your software is buggy and you should fix it. Stop whining and learn to use your language properly.

>>955334

>requires 1,000 times more testing effort

>yet ships completely untested software

>confused why it has a reputation for being a buggy pile of shit used by LARPers who think watching a compile makes them a developer

>>955337

>>requires 1,000 times more testing effort

If your software breaks because of compiler flags that you didn't consider then it's most likely because you rely on undefined behavior. Such bugs do not occur due to lack of testing but because you're using the language wrong. Stop making up excuses.

>>955347

>It doesn't actually matter why it breaks, just that it breaks.

You're still looking for excuses for your bad code. If you rely on UB, your code can fail silently without you noticing it. The compiler can and will (rightfully so!) optimize away your security checks if you're not careful.

>-ffast-math

>relying on specific float precision

C makes few guarantees regarding their precision anyway. If you need precision, use gmp.

>>955354

>relying on things that are reliable

What was I thinking.

>>955355

The C standard requires float to be represented in IEEE 754 format, but only if STDC_IEC_559 is defined. Otherwise other floating point representations may be used. See https://wiki.sei.cmu.edu/confluence/display/c/FLP00-C.+Understand+the+limitations+of+floating-point+numbers

>>955359

>program requires IEEE float

>ignore warnings from the compiler team about breaking it

>ignore warnings from the distro maintainers about breaking it

>break it

>break emulation of it

>program breaks

>post bug report

>get laughed at as ghentooman, marked INVALID

>cry on imageboard

>>955380

Don't pretend you've ever checked for STDC_IEC_559.

>>955380

>>955384

$ cat test.c
#include <stdio.h>
int main()
{
	#ifdef __STDC_IEC_559__
	puts("IEEE");
	#else
	puts("no IEEE");
	#endif
	return 0;
}
$ cc -o test test.c && ./test
IEEE
$ cc -ffast-math -o test test.c && ./test
no IEEE

>>955385

Daily reminder that no non trivial codebase is actually c standard compliant and that the standard is a piece of shit full of UB that makes trivial things difficult.

>>955384

>implying you can portably support esoteric fp hardware

>>955394

That's the trade off for a fast, low level, portable language.

>>955395

You can't. That's why C makes no guarantees.

>>955385

>it's your fault for not checking that I broke it

>t. ghentooman

Nah fam, you fucked up.

>>955403

>My bugs are other people's fault

Keep telling that to yourself, Pajeet :3

>>955406

>bug-free code

>ignore warning not to add a bug

>complain about bug

I don't know what you expected but I want to laugh at you. You are the stereotypical source-based distro user who has broken all his packages and can't understand why GNOME crashes every 5 minutes.

>>955400

>That's the trade off for a fast, low level, portable language.

Yeah it's so low level it actually fails to target anything correctly.

>>955400

>That's the trade off for a fast

yeah man memory leaks and crashing are real fast way to finish running a program

>>953155 (OP)

The world runs on Dunkin, fucker.

>>955416

what's dunkin?

>>955418

donut shop in the good ol' US of A

C, the programming language, is to computer engineering, as C, the element, is to organic chemistry.

>>956636

It's an important ingredient for bugs, yes.

>>953730

>What sucks about UNIX culture is that they >measure value by the amount of code instead >of by functionality, quality, and usefulness. >That's probably why they prefer monolithic >monstrosities like Linux over microkernels >where people can write drivers in whatever >language they want.

could you give me an example of a kernel/system that you prefer? not trying to start an argument, just genuinely curious.

>>956708

fugg my phone fucked it up

>>956636

I believe this would be less of a problem if C tutorials didn't teach how to write a hello world but instead how to write a portable, UB free hello world.

>>953730

>>956708

>What sucks about UNIX culture is that they measure value by the amount of code

Indeed! Ken Thompson once said "One of my most productive days was throwing away 1000 lines of code."

>>956712

Have in mind that Ken Thompson, and everyone from that era, worked with computers that were very limited in memory, so it makes sense to try to reduce the footprint of the programs to have more memory available.

>>956771

And in our era, we're working with computers that have very little fast cache, with main memory being two orders of magnitude slower than the CPU working it. It still makes sense to fit as much as possible in the cache for performance reasons.

>>955309

>>make a game for it in your spare time

>>decide to port it to a smaller, cheaper machine

UNIX came about afterwards because AT&T paid them to write an OS. No "backwards compatibility" with the game had any effect on UNIX because it's different code.

>>Bell labs is interested again and ends up owning UNIX, publishes first version

This is when they should have fixed the problems instead of forcing them on the users. Anywhere but AT&T, these bugs would have been fixed in the decade between being "research" and becoming a product, but instead these bugs are still there in 2018 and they will never be fixed.

>>Dennis gets crazy idea

That crazy idea came directly from Multics.

>>"let's write the OS in a higher level language, in a way that it can be compiled for different machines"

There were already better languages that did this. The only "innovations" of C were array decay and requiring all the machines to resemble a PDP-11, which suck.

>>956636

"Computer engineering" is more than PDP-11 copycats like RISC and AMD64 (x86 without the good parts). C happens to be what's supported by the PDP-11. It only has the bitwise operations the PDP-11 had, no implication, nor, nand, etc. It has no nested functions because the PDP-11 has no support for downward funargs. Arrays decay to pointers because the PDP-11 hardware has no array data type. Unions don't keep track of the current type because the PDP-11 has no tagged memory. Lisp machines have all of this. UNIX weenies like to think hardware is generic and doesn't matter, but C is a virtual PDP-11. If UNIX with the same "philosophy" originated on a Lisp machine, mainframe, or x86, it would look a lot different than it does.

>>956708

Multics, Lisp machines, and VMS. VME also seems good because it follows the Multics philosophy.

>>956712

>>What sucks about UNIX culture is that they measure value by the amount of code

What I said here is correct. Firefox and Linux are valuable because of their code size. The large size of these programs attract developers and users because they think these projects are big because they provide that much value, not because they're bloated and use bad languages like C that need more code.

>Indeed! Ken Thompson once said "One of my most productive days was throwing away 1000 lines of code."

Throwing away UNIX entirely would be even more productive, but I'm interested in what code he threw away. UNIX has so many redundant "tools" and useless command options that you could throw away a lot more than 1000 lines of code without anyone noticing. On the other hand, throwing away code can also mean removing error handling, drivers, and other things people care about, at least when they don't work.

   Maybe the idea of a portable operating system is a good
   thing, but unfortunately, they only invented the idea,
   but still haven't come up with an implementation.

Multics was written in a high-level language first.  ITS ran
on the PDP-6 and PDP-10.

Sure they came up with an implementation.  You just make a
machine that looks just like a PDP-11 and you can port unix
to it.  No problem!

The latest idea is to build machines (RISC machines with
register windows) which are designed specifically for C
programs and unix (just check out the original Berkeley RISC
papers if you don't believe me: it was a specific design
goal).  Now, people tell me that the advantage of a Sun over
a Lisp machine is that it's a general-purpose machine ("Of
course it's general purpose." they say.  "Why it even runs
unix.").

Hmm, well this example shows that at least the weenix unies
know how to USE recursion!

>>956771

Another reason for less code is human manageability. Modern computers have lots of memory, we know this. What hasn't changed though is the the capacity of the human brain.

Less code is better for maintainability, auditing, and human efficiency. The idea that we can bloat our code simply because our computers can handle it leads to increased system requirements and the introduction of more bugs that will go unfixed. Less is more.

>>957002

>"Computer engineering" is more than PDP-11 copycats like RISC and AMD64 (x86 without the good parts).

Fair enough. But those are very much entrenched and established.

>C happens to be what's supported by the PDP-11. It only has the bitwise operations the PDP-11 had, no implication, nor, nand, etc. It has no nested functions because the PDP-11 has no support for downward funargs.

I don't really think of lacking ->, nor, or nand as particularly great losses. Either way, you could syntax sugar it in. ^_^

>Arrays decay to pointers because the PDP-11 hardware has no array data type.

You can choose PL/I, or you can choose Stroustrup C.

I don't know if this is just because we all grew up immersed in C, but I don't think there really is an "array" type at the assembly level? It's all bytes at the end.

>Unions don't keep track of the current type because the PDP-11 has no tagged memory. Lisp machines have all of this.

Do our current machines have tagged memory?

>UNIX weenies like to think hardware is generic and doesn't matter, but C is a virtual PDP-11. If UNIX with the same "philosophy" originated on a Lisp machine, mainframe, or x86, it would look a lot different than it does.

Obviously.

>>957002

>AMD64 (x86 without the good parts)

Wat. You're full of shit.

> It has no nested functions

Yes it does.

>Arrays decay to pointers because the PDP-11 hardware has no array data type.

Why would a CPU have an 'array data type'?

>Unions don't keep track of the current type because the PDP-11 has no tagged memory.

Tagged memory is a waste of space. If you want to tag data, implement it yourself.

>UNIX weenies like to think hardware is generic and doesn't matter, but C is a virtual PDP-11.

Hardware is generic and doesn't matter. C is a portable language to support generic hardware.

>If UNIX with the same "philosophy" originated on a Lisp machine, mainframe, or x86, it would look a lot different than it does.

>Lisp machine

probably

>mainframe

I don't know

>x86

If you mean 286 and earlier then yes, it would have support for segmented memory, which would be retarded tbh in fact it does, at least partially. For example, you can't compare pointers from different allocations because they may be in different segments. If you mean 386 and later, then no.

>The large size of these programs attract developers and users because they think these projects are big because they provide that much value

Developers are regularly scared off by the code size. Users don't know about the code size, nor do they care.

.>>956933

We have obscene amounts of fast cache today, it just gets wasted by most programs.

>>957094

No, the large caches are still order of magnitude slower than the CPU cores. The fast L1 cache rarely exceeds 64kB in size.

learn to link, faggot

>>957002

>>953730

>>953618

>>953608

Where are these quotes from?

>>953678

You'd expect that to work, but it doesn't, because overflow is undefined. If the compiler can prove that y is positive, it's allowed to assume that x + y > x is always true.

$ cat overflow.c
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char **argv)
{
    int x = atoi(argv[1]);
    int finalx = x + 1;
    if (finalx < x) {
        puts("overflow");
    } else {
        puts("all is well");
    }
    printf("%d\n", finalx);
}
$ gcc -O0 overflow.c -o overflow-unoptimized
$ gcc -O1 overflow.c -o overflow-optimized
$ ./overflow-unoptimized 2147483647
overflow
-2147483648
$ ./overflow-optimized 2147483647
all is well
-2147483648

Notice that finalx is the same in both cases, so the real result is the same. But if you compile it with -O1 or higher, the finalx < x branch is optimized away.

>>953198

???

clang compiles much quicker than gcc

>>959868

*being "weird"

>>957083

>ignore how most cancer plaguing large projects like Firefox and Linux is pushed by corporate shitters who openly despise Unix and its "everything is a file" autism

Firefox being a bloated piece of shit has absolutely nothing to do with adhering or not to "the UNIX way".

>>955395

daily reminder that idiots like this exist who think UB=portability

>>955330

Uhhh so changing O1 to O2 is breaking programs? So you are just adding to my point. Most software is crap and doesn't state its dependencies, thus only the biggest distros will have most of the exact dependencies required to not trigger bugs. Harderning in Linux is shit in general, but that's not a Gentoo specific problem.

>rarely a bug

Nope that's an exaggeration or you are just counting noob posts.

>>953489

This is equivalent to saying that white people undeservingly stumbled into their position of relative wealth and high civilisation. There has long been a myriad of languages to choose from. C survived the process of natural selection. C was the fittest.

>>959912

C is like American blacks in the inner city. In the early 20th century, New York City and Detroit were more than 98% white.

>>959969

So what you are saying is that C is like niggers.

Outlived it's usefullness, better alternatives are available, but for some reason we keep it around even though it is causing all kinds of problems.

Sounds about right to be honest.

>>959969

>>959974

This. C is obsolete, Javascript is the future.

Your boss owns your ass. How do you feel?

>>959890

>Uhhh so changing O1 to O2 is breaking programs?

It could, but software is almost always designed for O2.

>Nope that's an exaggeration

Nope, it's a meme. It's not worth the effort tracking down a bug that might be unique to not only the user's flags, but to a unique set of versions of dependencies at the time they reported it that even they no longer have the exact versions of which were packaged by amateurs and have data not properly migrated between releases.

Like the guy in the other thread complaining that GNOME 3 sucks because it "crashes every 5 minutes", and on asking him, yep, gentooman. It's a huge waste of time debugging anything on the systems they've destroyed.

>>959912

But look at white people today: your average Millennial or Gen Z thinks that all other white people don't deserve their wealth and all other' white people should give it to "minorities" They, of course, deserve their wealth and position and have no obligation to give anything to anyone. Such is SJW "justice".

Face it, unless we greatly cull the herd, white people are a dead end.

>>960010

> all other white people don't deserve their wealth and all other'

> all other white people don't deserve their wealth and all other

I fucking hate this shitty ass keyboard.

>>960062

Absolutely destroys what faggots, Terry? The ones who think that the Internet is the fucking world? The ones who are too retarded to know that all the traffic lights and elevators and planes and trains and ships and robots are written in non-cancerous languages? Of the 9 computerized appliances in my house (urban Amish), only 3 are programmed in C. The assertion that the world runs on C is an argument from ignorance, or an argument that "the Internet" is the whole world, which is pathetic.