|
Yeah, none of that is a surprise if you read the spec. The fact that it will be a surprise for anyone coming from a decent language combined with the fact that JS is becoming the most popular language in the industry is the real horror. quote:
Yep. "Invalid string length" is what I'm getting out of Chrome (on OSX). quote:
That's a ~8.6 GB string, so it's probably blowing the per-process memory limit.
|
# ? Mar 31, 2016 18:35 |
|
|
# ? Jun 8, 2024 07:43 |
hackbunny posted:The scary/cool reason for this is that index 0 contains the length of the string The "classic" Pascal-string type is a 256 byte buffer, where the first entry is an unsigned byte specifying the valid length of the buffer. You can also declare buffers shorter than that, but they still have the length marker byte. The dynamic string type introduced in Delphi is actually called AnsiString, and is a pointer to a ref-counted CoW string object, that also contains length information. You can access the string bytes by array indexing, but not the length, and it's not a real class with member functions/methods. hackbunny posted:This is because Pascal is not a dynamic language and type information is lost at runtime Again except for Delphi, which has some kind of magic for IDispatch COM classes (I believe), and some other magic to access controls on dynamically created TForm instances by the Name property assigned to the controls from code. E.g. I believe this will work (written from memory, may not compile): code:
|
|
# ? Mar 31, 2016 19:45 |
|
Munkeymon posted:Yeah, none of that is a surprise if you read the spec. The fact that it will be a surprise for anyone coming from a decent language combined with the fact that JS is becoming the most popular language in the industry is the real horror. Oh, I'm not surprised by any of this - JS has it's quirks; I was just continuing the array indexes theme. Still, this is my favorite, this time from php - http://sandbox.onlinephpfunctions.com/code/87319d093bf5bd59d28cf9c876183ee5d6c40948 code:
quote:array(1) { Whereas going with pow(2,64) will overflow and make the $index 0 On my local: code:
quote:array(1) { [-2147483648]=> string(1) "f" } type casting is a bitch var_dump(intval($index-10), intval($index), intval($index+10)); int(2147483638) int(-2147483648) int(-2147483638) canis minor fucked around with this message at 20:23 on Mar 31, 2016 |
# ? Mar 31, 2016 19:52 |
|
Shinku ABOOKEN posted:Name and shame. The UK also has insane libel laws, so better not.
|
# ? Mar 31, 2016 20:57 |
|
canis minor posted:
Type casting isn't a bitch, PHP is just totally insane and always will be.
|
# ? Mar 31, 2016 21:36 |
|
PHP and JS are both cheating in this thread tbh
|
# ? Mar 31, 2016 21:37 |
|
TheresaJayne posted:sounds bad, Unionize. Just saying...
|
# ? Mar 31, 2016 21:54 |
|
Vanadium posted:Strings can be longer than 65536 chars! nielsm posted:The "classic" Pascal-string type is a 256 byte buffer, where the first entry is an unsigned byte specifying the valid length of the buffer. You can also declare buffers shorter than that, but they still have the length marker byte.
|
# ? Mar 31, 2016 22:02 |
|
hackbunny posted:The scary/cool reason for this is that index 0 contains the length of the string That's kinda similar to the way dynamically allocated arrays are implemented in most C++ compilers, really. Get a block of memory slightly larger than what you need, stick the number of elements in the array at the beginning, and return a pointer to the first array element to the user. Sometimes I kinda wish that value was accessible to programmers, but since compilers are free to implement dynamically allocated arrays however they want it probably would have been more trouble than it's worth.
|
# ? Mar 31, 2016 22:39 |
|
God I was about to write a whole stupid reply to this before realizing, yeah, delete[] has to work somehow.
|
# ? Mar 31, 2016 22:47 |
|
Longer than 65535 chars I guesss
|
# ? Mar 31, 2016 23:21 |
|
YeOldeButchere posted:That's kinda similar to the way dynamically allocated arrays are implemented in most C++ compilers, really. Get a block of memory slightly larger than what you need, stick the number of elements in the array at the beginning, and return a pointer to the first array element to the user. Nope, even K&R C got this mind-numbingly stupidly wrong. Arrays should be prefixed with the length and return a pointer to the first element to the user. Bonus: arrays become first-class objects you can pass between functions, rather than decaying to pointers. sizeof() allows anyone to safely iterate a received array, dynamic or stack allocated. Everyone wins! Instead we have decades of trivial buffer overflows and stack-smashing. Thanks guys. edit: I'm aware of some of the objections, I just don't agree. I don't believe any of the performance wins are worth Blaster, Sasser, Slammer, Code Red, Heartbleed, and a continuously growing list of literally thousands of root-level exploits across a huge variety of systems. Heartbleed was so bad it required every single human being on the planet to change their passwords and quite possibly exposed huge volumes of SSL traffic to snooping/spying. It may have literally lead to people's deaths as bad actors (or state security agencies) took advantage of it to track dissidents or "troublesome" people. C could have had arrays/strings that were much safer by default. K&R made the wrong choice, and I'll stand by that statement any day of the week. Simulated fucked around with this message at 23:17 on Apr 1, 2016 |
# ? Apr 1, 2016 05:41 |
|
I've always assumed that C went with null-terminated strings because it lets you do in-place tokenization tricks and passing a pointer midway into a string without needing to reallocate anything makes writing recursive descent parsers very simple. They picked the representation that makes it easy to write a self-hosting compiler, and every other application paid the price.
|
# ? Apr 1, 2016 05:55 |
|
Internet Janitor posted:I've always assumed that C went with null-terminated strings because it lets you do in-place tokenization tricks and passing a pointer midway into a string without needing to reallocate anything makes writing recursive descent parsers very simple. They picked the representation that makes it easy to write a self-hosting compiler, and every other application paid the price. Yeah, a lot of design tricks were needed to bootstrap a self-hosting compiler for a portable language and an OS written in it on a machine that generally shipped with 24 kilobytes of RAM.
|
# ? Apr 1, 2016 06:05 |
|
Ender.uNF posted:Nope, even K&R C got this mind-numbingly stupidly wrong. Arrays should be prefixed with the length and return a pointer to the first element to the user. Bonus: arrays become first-class objects you can pass between functions, rather than decaying to pointers. sizeof() allows anyone to safely iterate a received array, dynamic or stack allocated. Everyone wins! You'd still need to have some way to define arrays like the ones we have now. Say you're writing code that screws around with memory-mapped i/o (eg device driver), you don't want your array to try shoving some length value into what may very well be a control register or some unallocated page or who knows what else. Even simpler than that, just taking a sub-array from a given array now requires you to make a copy instead of just having a pointer to the first element of the sub-array with a length. That's kind of a big deal, and I'm pretty sure that anyone who writes numerical code would be very unhappy, among others. I'm also going to assume that by "sizeof()" you mean "something like sizeof()", because having it deal with runtime type information instead of just compile time info like it does now would be unpleasant at best. sizeof returning compile-time constants is kind of useful.
|
# ? Apr 1, 2016 06:42 |
|
YeOldeButchere posted:You'd still need to have some way to define arrays like the ones we have now. Say you're writing code that screws around with memory-mapped i/o (eg device driver), you don't want your array to try shoving some length value into what may very well be a control register or some unallocated page or who knows what else. Even simpler than that, just taking a sub-array from a given array now requires you to make a copy instead of just having a pointer to the first element of the sub-array with a length. That's kind of a big deal, and I'm pretty sure that anyone who writes numerical code would be very unhappy, among others. quote:I'm also going to assume that by "sizeof()" you mean "something like sizeof()", because having it deal with runtime type information instead of just compile time info like it does now would be unpleasant at best. sizeof returning compile-time constants is kind of useful. sizeof already does this. C99 isn't very pleasant. (tgmath also sucks)
|
# ? Apr 1, 2016 07:44 |
|
YeOldeButchere posted:That's kinda similar to the way dynamically allocated arrays are implemented in most C++ compilers, really. Get a block of memory slightly larger than what you need, stick the number of elements in the array at the beginning, and return a pointer to the first array element to the user. PL/I "Varying strings" are an array of chars, preceded by a 16-bit length word. That allow CHAR VAR up to 32.767 bytes (yep, for whatever reason the length word is signed). If you take a pointer to a CHAR VAR you get the address of the length prefix. That, combined with BASED storage allow the programmer to do all sorts of nasty things using varying strings. For instance, to use varying length records (remember old times operating systems had a notion of "record" beyond "arbitrary stream of bytes), overlaying a CHAR VAR with several different structures and manipulating the record length by hand So I guess that's score one for Old Farts.
|
# ? Apr 1, 2016 16:22 |
|
YeOldeButchere posted:That's kinda similar to the way dynamically allocated arrays are implemented in most C++ compilers, really. Get a block of memory slightly larger than what you need, stick the number of elements in the array at the beginning, and return a pointer to the first array element to the user. cfront on HP-UX used to do it differently. It stored the array size in a separately allocated block of memory, causing a slow memory leak when you deleted an array using the non-array delete operator. (This was ~25 years ago, I may not remember the details correctly.)
|
# ? Apr 1, 2016 17:10 |
|
Zopotantor posted:The UK also has insane libel laws, so better not. Not that bad these days actually, check out https://en.wikipedia.org/wiki/Defamation_Act_2013 Similarly we no longer wear top hats, ride around in carriages or have 'pea soupers'! Edit: that cfront implementation choice is exactly why delete[] exists as a separate thing in the first case, I believe.
|
# ? Apr 1, 2016 17:11 |
|
Ender.uNF posted:Nope, even K&R C got this mind-numbingly stupidly wrong. Arrays should be prefixed with the length and return a pointer to the first element to the user. Bonus: arrays become first-class objects you can pass between functions, rather than decaying to pointers. sizeof() allows anyone to safely iterate a received array, dynamic or stack allocated. Everyone wins! There are plenty of arguments to make against C arrays, but this is the stupidest idea.
|
# ? Apr 1, 2016 17:44 |
|
Ender.uNF posted:Nope, even K&R C got this mind-numbingly stupidly wrong. Arrays should be prefixed with the length and return a pointer to the first element to the user. Bonus: arrays become first-class objects you can pass between functions, rather than decaying to pointers. sizeof() allows anyone to safely iterate a received array, dynamic or stack allocated. Everyone wins!
|
# ? Apr 1, 2016 18:10 |
|
b0lt posted:sizeof already does this. C99 isn't very pleasant. (tgmath also sucks) I had no idea variable-length arrays were a thing that existed, and I think I liked it better that way.
|
# ? Apr 1, 2016 18:18 |
|
This Perl 6 slide deck popped up on HN last night and I figured this thread would appreciate it. Perl 6 looks like a lot of fun, but it also looks like it'll be even more write-once than ever before.
|
# ? Apr 1, 2016 18:30 |
|
http://tpm2016.zoffix.com/#/40 # OUTPUT: # 「250.42」 # sign => 「」 # digits => 「250」 # decimal => 「.42」 # digits => 「42」 More weeaboo than Ruby. Edit: Christ, Something Awful.
|
# ? Apr 1, 2016 19:01 |
|
sarehu posted:http://tpm2016.zoffix.com/#/40 lol
|
# ? Apr 1, 2016 19:03 |
|
Perl 6: hey I know, let's try to reclaim the title for more insane language from JS and PHP!
|
# ? Apr 1, 2016 19:11 |
|
xzzy posted:Perl 6: hey I know, let's try to reclaim the title for more insane language from JS and PHP! Now, now, Perl mostly makes sense. It's just illegible and lets you do crazy things with it.
|
# ? Apr 1, 2016 19:14 |
|
A language allowing you to do crazy things is one thing, but a language where "do the craziest things imaginable with these techniques, all the time" is the fundamental theme of every tutorial? That's where the reputation of insanity comes from. That's cultivating a culture of obfuscation even worse than Perl 5's.
|
# ? Apr 1, 2016 19:23 |
|
you can't really blame them for focusing on wacky features. they're constantly faced with the question "why should i come back to perl when i stopped caring about it 15 years ago", and "you can't write poo poo like this in whatever dull plang you use today, don't you wish you could write poo poo like this" is the answer they seem to have settled on.
|
# ? Apr 1, 2016 19:32 |
|
I like the slide with the gears that can't possibly turn: http://tpm2016.zoffix.com/#/43
|
# ? Apr 1, 2016 19:48 |
|
sarehu posted:http://tpm2016.zoffix.com/#/40 This looks a lot like Clojure's instaparse library for Context-Free Grammars. But with native language support?
|
# ? Apr 1, 2016 21:45 |
|
YeOldeButchere posted:You'd still need to have some way to define arrays like the ones we have now. Say you're writing code that screws around with memory-mapped i/o (eg device driver), you don't want your array to try shoving some length value into what may very well be a control register or some unallocated page or who knows what else. Even simpler than that, just taking a sub-array from a given array now requires you to make a copy instead of just having a pointer to the first element of the sub-array with a length. That's kind of a big deal, and I'm pretty sure that anyone who writes numerical code would be very unhappy, among others. That would only be true if you're storing a pointer to the subarray, otherwise the compiler can just pass the array as a pointer and add a hidden length parameter. The key there being you aren't relying on the programmer to get it right. You can bike shed the design all day but there are going to be tradeoffs. My point is that the tradeoffs would be worth it. How many billions of dollars in damages have happened due to buffer overflows? Maybe in the $trillions by now. Many, many, many RCE exploits (even ROPs) start with a simple buffer overflow. rjmccall posted:There are plenty of arguments to make against C arrays, but this is the stupidest idea. Precondition: You're designing K&R C but you want to make avoiding buffer overflows easier and automatic for the common case. What do you do? Volte posted:Sounds like you want a language other than C. Not to mention you could trivially(?) create a structure that contains a size_t and a pointer that does exactly what you say. You'd need a bit of machinery to malloc/alloca your array up but if you want to be more memory-safe you can put in the effort and do it. If you want it to happen automatically, then you're barking up the wrong tree. Anything that relies on humans to be less lazy and/or better programmers is destined to fail. C is worse in that it actively prevents you from designing any kind of tooling to enforce memory safety or opting-in to bounds-checked arrays even if you want to use them. Even if your own code chose to employ the solution you mention it's a non-starter because none of the libraries you rely on will adopt your bespoke array type. It wouldn't be so bad if you could just throw a compiler switch, accept a 20-30% performance hit, but know that it was almost impossible to smash the stack or run off the end of a buffer. We'd all add that flag and we'd scream at and look down on anyone who didn't because they'd be a moron to trade a small performance boost for such massive security risks except in certain limited situations (embedded micro controllers with 2k RAM for example). My supposition is that C arrays are badly designed and actively promote security vulnerabilities while simultaneously closing off many potential mitigations even if a user of C wanted to opt in to them. So far I'm not hearing any arguments that C arrays are a good design, just that they have some performance advantages. So does running all code in Ring 0 without memory protection.
|
# ? Apr 1, 2016 23:36 |
|
Ender.uNF posted:It wouldn't be so bad if you could just throw a compiler switch, accept a 20-30% performance hit, but know that it was almost impossible to smash the stack or run off the end of a buffer. We'd all add that flag and we'd scream at and look down on anyone who didn't because they'd be a moron to trade a small performance boost for such massive security risks except in certain limited situations (embedded micro controllers with 2k RAM for example). As much as I enjoy hearing my entire career exists in "limited situations," your compiler flag has existed for over a decade and strangely hasn't been baked into everything like you predicted.
|
# ? Apr 1, 2016 23:41 |
|
This is fun (again JS):code:
quote:... https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER canis minor fucked around with this message at 00:13 on Apr 2, 2016 |
# ? Apr 2, 2016 00:09 |
|
JS like JS. It's a language, it has its quirks and .. oh well, you learn to live with them. But the developers... that's the real WTF. The kids that run the npm showshit, the contributors, the lego "programmers" who write that horrifically wrong line of code that gets published without any oversight and gets used over and over again (because nobody knows any better), that's the real WTF. And they call themselves developers. Full stack developers. They put that poo poo on the server-side where things like is_int or _is_array should have never been even questions, and yet they are. But .. I'm the old-fashioned one. Why are they even allowed anywhere close to a computer?
|
# ? Apr 2, 2016 01:05 |
|
Ender.uNF posted:Precondition: You're designing K&R C but you want to make avoiding buffer overflows easier and automatic for the common case. What do you do? Have an array-ref type, including a dynamically-sized variant which can be dynamically constructed from a pointer and length, and have array l-values decay to that. Subscript only works on an array or array-ref, not a pointer. You can still take the address of an array element and get a pointer back. The stupid part of your idea is just storing the length before the first element and thus preventing the builtin array support from being applied to an array not separately and specifically allocated by the programmer, not the concept of having bounds information available dynamically.
|
# ? Apr 2, 2016 02:02 |
|
canis minor posted:This is fun (again JS): Whats the problem here?
|
# ? Apr 2, 2016 02:24 |
|
HappyHippo posted:Whats the problem here? For example - 2^64 shouldn't equal (or be identical to) 2^64 - 2^10. I know that stems from how numbers are being stored, but if operations on large numbers can't be trusted, shouldn't there be an exception instead?
|
# ? Apr 2, 2016 02:30 |
|
canis minor posted:For example - 2^64 shouldn't equal (or be identical to) 2^64 - 2^10. I know that stems from how numbers are being stored, but if operations on large numbers can't be trusted, shouldn't there be an exception instead? Floating point errors can't be detected in that sense. Every time something is rounded there is a potential for an error like that and almost every operation results in rounding of some sort. So I don't know how you'd expect it to throw an exception. Edit: Also this has basically nothing to do with Javascript
|
# ? Apr 2, 2016 02:47 |
|
|
# ? Jun 8, 2024 07:43 |
|
These are the issues you run into when using https://en.wikipedia.org/wiki/IEEE_floating_point for numbers your ignorant users think are integers.
|
# ? Apr 2, 2016 03:05 |