Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time safety is more important than memory safety

halestrom.net

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Time safety is more important than memory safety

#101

Post by dnautics »

ratboy666 wrote: post #87
ratboy666 wrote: post #36

Earlier quoted context omitted.

As part of "C lore", the answer is yes. In C89: int main() { func('a'); } func(c) char c; { char * s = &c; printf("%c\n", * s); } is, um, dangerous. c is an int, not a char. So on a big endian machine, s may end up pointing to the high byte. Taking the address of a parameter is dangerous, unless the widening is taken into account. This does work on a little endian machine (tried it). On a 68000, it likely doesn't pri…

And, for those who have been contemplating parameter widening: on the 68000, insert s += 3. For "portable" C89 code, declare the parameter an int (not char) -- then introduce char c2 = c and s = &c2 instead. This transformation is "safe" because parameters are copied by value and cannot be returned that way. As to debugging -- many of these systems did not have "debuggers" -- an example would be Whitesmiths C in the…

Elixir has just feature frozen itself and it looks like it won't 2.0 (the underlying erlang subsystems might change, though).

You might like zig which is shaping up to be a saner c, and Andy Kelly looks like he's staving off feature creep.

Re: Time safety is more important than memory safety

#102

Post by pasabagi »

downerending wrote: post #100
pasabagi wrote: post #98

Earlier quoted context omitted.

I've never really dug into C++, but I've written a little bit of C, and I feel it's generally easier to write a given program in Rust than it is in C. I can see why Rust has its reputation for difficulty - the burrow checker is a new idea, and the unfamiliar is inherently dificult. However, I think once you've spend a modicum of time, it's a fairly straightforward language, simply because the compiler almost always t…

That may be, but debugging "looks like work" in the eyes of mgmt. The borrow checker, on the other hand, looks more like "I can't find any applicants in Little Rock who can do this stuff.".

On the other hand, I think the most important thing in making developers replaceable is the degree to which the codebase explicitly contains all the information relevant to it.

Lifetimes are an additional, important piece of information that would have previously been something a programmer would have to have an intuition for, or that would need to be put in documentation.

Now, that work is delegated to the compiler, and so, your individual developer is somewhat more fungible.

I don't know if rust is specifically the future in this regard, but I think if I was a machivellian manager, I'd be interested in replacing instances of human intuition and group knowledge with tooling, as much as possible. The burrow checker is one such tool - even if automatic garbage collection is probably a more straightforward one.

Re: Time safety is more important than memory safety

#103

Post by Akira1364 »

benibela wrote: post #16

I use Pascal for all my projects because it has memory safe strings and arrays. Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal. Everytime a software crashes, you should say, it crashed, because it was not written in Pascal I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a…

This is a very strange comment IMO. There are already perhaps too many XML and JSON handling libraries for Object Pascal, as well as libraries for pretty much anything else I can think of.

Re: Time safety is more important than memory safety

#104

Post by Akira1364 »

dana321 wrote: post #28
benibela wrote: post #16

I use Pascal for all my projects because it has memory safe strings and arrays. Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal. Everytime a software crashes, you should say, it crashed, because it was not written in Pascal I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a…

You would probably like go, its much like pascal. And it has libraries for everything!

Two things:

A) The person you're replying to is simply quite wrong about the amount of Pascal libraries available. There is no "domain of interest" I can think of that does not have at least one "defacto" library for it.

More commonly though there's four, five, six or more libraries for any given thing to choose from, which often turn out to each have specific strengths such that you may very well end up using more than one of them in your project.

B) They would almost certainly probably not like Go. Object Pascal as implemented by Free Pascal is a language that effectively embraces with open arms almost all of the things that Go actively avoids: for example, traditional (single) inheritance, operator overloading, both function overloading and generics, and so on and so forth.

As far as inheritance specifically, the general indifferent attitudes towards it of "there are definitely times and places where it makes more sense than anything else to use" amongst Pascal programmers are in my opinion basically a direct result of the fact that "bad experiences the compiler developers personally had with inheritance as specifically implemented by C++" are NOT something that actively factors into their decision making process or something that they really think about or care about at all (or more broadly, something that users of the compiler generally think about or care about at all).

This sets it quite far apart from other languages such as Rust, where "things C and C++ arguably did wrong" are in fact heavily influential and both thought about and discussed regularly.

Re: Time safety is more important than memory safety

#105

Post by AnimalMuppet »

benibela wrote: post #16

I use Pascal for all my projects because it has memory safe strings and arrays. Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal. Everytime a software crashes, you should say, it crashed, because it was not written in Pascal I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a…

This reads like trolling. "It crashed, because it was not written in Pascal"? Come on.

It may have crashed because it was written in C/C++, perhaps. But on the exact same grounds, why not say "It crashed because it was not written in Haskell"? (Or any of several other languages.) Why Pascal in particular?

Re: Time safety is more important than memory safety

#106

Post by ratboy666 »

flavio81 wrote: post #89
dana321 wrote: post #28

Earlier quoted context omitted.

You would probably like go, its much like pascal. And it has libraries for everything!

Last time I checked, Pascal has generics and exception handling.

Pascal has neither generics nor exception handling. At least, with reference to ISO Pascal.

Re: Time safety is more important than memory safety

#107

Post by timbit42 »

AnimalMuppet wrote: post #105
benibela wrote: post #16

I use Pascal for all my projects because it has memory safe strings and arrays. Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal. Everytime a software crashes, you should say, it crashed, because it was not written in Pascal I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a…

This reads like trolling. "It crashed, because it was not written in Pascal"? Come on. It may have crashed because it was written in C/C++, perhaps. But on the exact same grounds, why not say "It crashed because it was not written in Haskell"? (Or any of several other languages.) Why Pascal in particular?

Because back in the 1970's, Pascal and C were the two languages battling it out. At the time C seemed like the best option of the two, but now that everything is online, we realize Pascal is the better option of the two.

Re: Time safety is more important than memory safety

#108

Post by benibela »

Akira1364 wrote: post #103
benibela wrote: post #16

I use Pascal for all my projects because it has memory safe strings and arrays. Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal. Everytime a software crashes, you should say, it crashed, because it was not written in Pascal I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a…

This is a very strange comment IMO. There are already perhaps too many XML and JSON handling libraries for Object Pascal, as well as libraries for pretty much anything else I can think of.

But do they work and are maintained? I do not trust them. At first I used the fpc xml parser, but it stores everything as utf-16 internally, and once it crashed on me during the utf-8 utf-16 conversion. I do not want to use utf-16 for anything, so that was a completely pointless crash.

Re: Time safety is more important than memory safety

#109

Post by benibela »

ratboy666 wrote: post #106
flavio81 wrote: post #89

Earlier quoted context omitted.

Last time I checked, Pascal has generics and exception handling.

Pascal has neither generics nor exception handling. At least, with reference to ISO Pascal.

Nobody refers to ISO Pascal anymore. It is either Delphi or FreePascal.

Re: Time safety is more important than memory safety

#110

Post by AnimalMuppet »

timbit42 wrote: post #107
AnimalMuppet wrote: post #105

Earlier quoted context omitted.

This reads like trolling. "It crashed, because it was not written in Pascal"? Come on. It may have crashed because it was written in C/C++, perhaps. But on the exact same grounds, why not say "It crashed because it was not written in Haskell"? (Or any of several other languages.) Why Pascal in particular?

Because back in the 1970's, Pascal and C were the two languages battling it out. At the time C seemed like the best option of the two, but now that everything is online, we realize Pascal is the better option of the two.

benibela doesn't sound like s/he is talking about the 1970s. Rather, the point seems to be crashes today.

But no, the people back then weren't fools wandering in darkness. C won not just because it appeared better, but because it was better. Pascal appeared better - it had better theory, and a better story. But for actually writing software, C was better. Even with all the "shoot yourself in the foot" potential, C was still better. Programming in Pascal was like picking your nose with boxing gloves on compared to programming in C. (I exaggerate, but Pascal was noticeably - and frustratingly - clumsier to use.)

Post reply on HN