digitalmars.D - foreach counter now must be size_t ?
- Johan Engelen (14/14) Feb 04 2019 This code now gives a deprecation message (>= 2.084):
- H. S. Teoh (9/24) Feb 04 2019 [...]
- Nicholas Wilson (2/16) Feb 04 2019 Thats a spec problem. The behaviour is very much deliberate.
- Walter Bright (2/3) Feb 04 2019 Which PR was it?
- Nicholas Wilson (2/5) Feb 04 2019 https://github.com/dlang/dmd/pull/8941
- Walter Bright (2/3) Feb 04 2019 Thank you, that's most helpful.
- Rubn (11/30) Feb 04 2019 I remember someone pointing out that foreach_reverse didn't
- Rubn (8/27) Feb 04 2019 Same goes for "sizeof32" which is especially annoying when
- Nicholas Wilson (2/21) Feb 04 2019 https://github.com/dlang/dlang.org/pull/2565/
- Timon Gehr (4/7) Feb 04 2019 I wish it wasn't. It seems this doesn't do anything useful. If I'm going...
- Adam D. Ruppe (3/7) Feb 04 2019 Ditto.
- Walter Bright (18/21) Feb 04 2019 It is the same thing as:
- Rubn (56/81) Feb 05 2019 WHAT. WHAT. Where do you see an assignment from size_t to int
- Walter Bright (2/10) Feb 05 2019 The ++i overflows and the loop never terminates.
- Rubn (2/13) Feb 05 2019 I'm saying SEMANTICALLY it is correct.
- Rubn (7/18) Feb 05 2019 Just as it is safe.
- Rubn (4/17) Feb 05 2019 This change to not allow int goes against the semantics of the
- Patrick Schluter (4/11) Feb 05 2019 Memory mapping archives and video files can easily get beyond 32
- Rubn (3/18) Feb 06 2019 I never knew arrays were files, thanks for the tip.
- H. S. Teoh (14/19) Feb 06 2019 [...]
- jmh530 (6/18) Feb 06 2019 mmap is something that I never really played around much with,
- H. S. Teoh (17/22) Feb 06 2019 It depends on how big your resident set size is, and what your memory
- jmh530 (2/3) Feb 06 2019 Very informative. Thanks.
- Walter Bright (4/8) Feb 06 2019 Executables are not loaded into memory before running them, they are mma...
- Rubn (8/18) Feb 07 2019 I'll take that to mean you don't think this is a bug:
- Jonathan M Davis (14/33) Feb 07 2019 If you're trying to say that you think that that's a compiler bug, then ...
- Rubn (4/44) Feb 08 2019 Good you agree it isn't a bug. Then we should remove this
- Jonathan M Davis (7/60) Feb 08 2019 It's not a compiler bug, but the code is still buggy. Using int for inde...
- Rubn (6/71) Feb 12 2019 It's a bandaid, the larger problem is allowing the comparison
- Rubn (8/73) Feb 12 2019 The point was, if you don't see the for() being an issue that has
- Nicholas Wilson (6/26) Feb 12 2019 The `for` is an issue, but one that is much harder to reason
- Kagamin (3/5) Feb 18 2019 The entire ecosystem is locked on unsigned integers, you can't
- Rubn (4/9) Feb 18 2019 This feature is currently in DMD, and they are breaking code to
- Walter Bright (3/4) Feb 07 2019 Use of such words will result in deletion of the posts. Please use profe...
- Rubn (4/8) Feb 08 2019 You can go ahead and delete the post if you want. It'd be no
- Nicholas Wilson (14/21) Feb 08 2019 Its not a bug. In the case that a.length > int.max, the loop will
- Rubn (2/25) Feb 08 2019 TIL infinite loop that freezes program isn't a bug.
- Norm (2/25) Feb 08 2019 It is a bug in your code, not the @safe.
- Olivier FAURE (11/12) Feb 08 2019 Specific language aside, there's a proper way to bring bugs to a
- Rubn (3/5) Feb 08 2019 Guess you weren't around, Walter's opinion on the matter is they
- Olivier FAURE (5/10) Feb 14 2019 Regardless.
- Rubn (13/33) Feb 06 2019 Not everyone is writing generic code. Especially in performance
- Tony (3/19) Feb 06 2019 Seems that the size_t would have to be a compiler variable we
- Dukc (7/8) Feb 05 2019 It does! Even I, who contribute only occasionally, have more than
This code now gives a deprecation message (>= 2.084): ``` void foo(int[] arr) { foreach (uint i, ref elem; arr) { } } ``` Deprecation: foreach: loop index implicitly converted from `size_t` to `uint` This is in contrast to the spec that says that "The index must be of int, uint, long or ulong type, it cannot be ref, and it is set to be the index of the array element." https://dlang.org/spec/statement.html#foreach_over_arrays Did someone forget to update the spec? Or is it a frontend bug? -Johan
Feb 04 2019
On Mon, Feb 04, 2019 at 10:26:08PM +0000, Johan Engelen via Digitalmars-d wrote:This code now gives a deprecation message (>= 2.084): ``` void foo(int[] arr) { foreach (uint i, ref elem; arr) { } } ``` Deprecation: foreach: loop index implicitly converted from `size_t` to `uint` This is in contrast to the spec that says that "The index must be of int, uint, long or ulong type, it cannot be ref, and it is set to be the index of the array element." https://dlang.org/spec/statement.html#foreach_over_arrays Did someone forget to update the spec? Or is it a frontend bug?[...] I'd expect the loop index should be of a type that can accomodate the largest possible array index. On 64-bit systems, that would be ulong, which size_t is aliased to when compiling for 64-bit. On 32-bit, size_t would be uint, so the above code should be compilable with -m32. T -- He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
Feb 04 2019
On Monday, 4 February 2019 at 22:26:08 UTC, Johan Engelen wrote:This code now gives a deprecation message (>= 2.084): ``` void foo(int[] arr) { foreach (uint i, ref elem; arr) { } } ``` Deprecation: foreach: loop index implicitly converted from `size_t` to `uint` This is in contrast to the spec that says that "The index must be of int, uint, long or ulong type, it cannot be ref, and it is set to be the index of the array element." https://dlang.org/spec/statement.html#foreach_over_arrays Did someone forget to update the spec? Or is it a frontend bug? -JohanThats a spec problem. The behaviour is very much deliberate.
Feb 04 2019
On 2/4/2019 3:01 PM, Nicholas Wilson wrote:Thats a spec problem. The behaviour is very much deliberate.Which PR was it?
Feb 04 2019
On Monday, 4 February 2019 at 23:30:54 UTC, Walter Bright wrote:On 2/4/2019 3:01 PM, Nicholas Wilson wrote:https://github.com/dlang/dmd/pull/8941Thats a spec problem. The behaviour is very much deliberate.Which PR was it?
Feb 04 2019
On 2/4/2019 4:54 PM, Nicholas Wilson wrote:https://github.com/dlang/dmd/pull/8941Thank you, that's most helpful.
Feb 04 2019
On Monday, 4 February 2019 at 23:01:06 UTC, Nicholas Wilson wrote:On Monday, 4 February 2019 at 22:26:08 UTC, Johan Engelen wrote:I remember someone pointing out that foreach_reverse didn't implicitly cast to int, but foreach did. Kind of sad they went to opposite way. Very rarely are you going to have an array that will fill a uint. If your type is only 1 byte that's 4 GB of memory. That's not a very common use case. If it's 4 bytes it grows to 16 GB which is more than the average consumer device has. Having to deal with length array being different for 32 and 64-bit is a pain. I ended up creating a function "length32" to avoid that garbage. If I ever have an array that can fill 32-bit then something has gone very wrong (in my use case).This code now gives a deprecation message (>= 2.084): ``` void foo(int[] arr) { foreach (uint i, ref elem; arr) { } } ``` Deprecation: foreach: loop index implicitly converted from `size_t` to `uint` This is in contrast to the spec that says that "The index must be of int, uint, long or ulong type, it cannot be ref, and it is set to be the index of the array element." https://dlang.org/spec/statement.html#foreach_over_arrays Did someone forget to update the spec? Or is it a frontend bug? -JohanThats a spec problem. The behaviour is very much deliberate.
Feb 04 2019
On Monday, 4 February 2019 at 23:01:06 UTC, Nicholas Wilson wrote:On Monday, 4 February 2019 at 22:26:08 UTC, Johan Engelen wrote:Same goes for "sizeof32" which is especially annoying when sometimes it evaluates to int because the value is known at the time and other times it evaluates to size_t cause it can't determine the value right away or is being used at runtime. If you a struct that can fill a uint something has gone extremely wrong and your executable file is going to be 4 GB minimum to accomodate the .init data.This code now gives a deprecation message (>= 2.084): ``` void foo(int[] arr) { foreach (uint i, ref elem; arr) { } } ``` Deprecation: foreach: loop index implicitly converted from `size_t` to `uint` This is in contrast to the spec that says that "The index must be of int, uint, long or ulong type, it cannot be ref, and it is set to be the index of the array element." https://dlang.org/spec/statement.html#foreach_over_arrays Did someone forget to update the spec? Or is it a frontend bug? -JohanThats a spec problem. The behaviour is very much deliberate.
Feb 04 2019
On Monday, 4 February 2019 at 23:01:06 UTC, Nicholas Wilson wrote:On Monday, 4 February 2019 at 22:26:08 UTC, Johan Engelen wrote:https://github.com/dlang/dlang.org/pull/2565/This code now gives a deprecation message (>= 2.084): ``` void foo(int[] arr) { foreach (uint i, ref elem; arr) { } } ``` Deprecation: foreach: loop index implicitly converted from `size_t` to `uint` This is in contrast to the spec that says that "The index must be of int, uint, long or ulong type, it cannot be ref, and it is set to be the index of the array element." https://dlang.org/spec/statement.html#foreach_over_arrays Did someone forget to update the spec? Or is it a frontend bug? -JohanThats a spec problem. The behaviour is very much deliberate.
Feb 04 2019
On 05.02.19 00:01, Nicholas Wilson wrote:I wish it wasn't. It seems this doesn't do anything useful. If I'm going through the trouble of explicitly specifying the counter type to be what I need, why annoy me with this error message?Thats a spec problem. The behaviour is very much deliberate.
Feb 04 2019
On Tuesday, 5 February 2019 at 03:15:03 UTC, Timon Gehr wrote:I wish it wasn't. It seems this doesn't do anything useful. If I'm going through the trouble of explicitly specifying the counter type to be what I need, why annoy me with this error message?Ditto. This change is bewildering to me.
Feb 04 2019
On 2/4/2019 7:15 PM, Timon Gehr wrote:I wish it wasn't. It seems this doesn't do anything useful. If I'm going through the trouble of explicitly specifying the counter type to be what I need, why annoy me with this error message?It is the same thing as: long l; uint i = l; // error D doesn't allow implicit narrowing conversions that lose information. If the foreach was written like this: void foo(int[3] arr) { foreach (uint i, ref elem; arr) { } } I.e. where the array bounds are known at compile time, then it works, because: enum long l = 3; uint i = l; also works. As for "who would ever have an array that big": 1. It's irrelevant, as the semantics of the language have to be sound across the uses it supports. 2. I noticed with Windows MovieMaker that it produces corrupt output files if the movie is bigger than 4Gb. Evidently a 32 bit counter isn't enough.
Feb 04 2019
On Tuesday, 5 February 2019 at 04:53:00 UTC, Walter Bright wrote:On 2/4/2019 7:15 PM, Timon Gehr wrote:WHAT. WHAT. Where do you see an assignment from size_t to int here? int[] arr = someRandomArray(); for( int i = 0; i < arr.length; ++i ) { dg( i, arr[i] ); } ??? There is only a comparison between `int` and `size_t` which is completely valid. And as far as I remember you strictly disapprove of even allowing a warning to be displayed in that case.I wish it wasn't. It seems this doesn't do anything useful. If I'm going through the trouble of explicitly specifying the counter type to be what I need, why annoy me with this error message?It is the same thing as: long l; uint i = l; // error D doesn't allow implicit narrowing conversions that lose information. If the foreach was written like this: void foo(int[3] arr) { foreach (uint i, ref elem; arr) { } } I.e. where the array bounds are known at compile time, then it works, because: enum long l = 3; uint i = l; also works.As for "who would ever have an array that big": 1. It's irrelevant, as the semantics of the language have to be sound across the uses it supports.If by semantics you are referring to the above, then see the above. Otherwise your misguided attempt to try and illustrate that a size_t can't be assigned to an int. Foreach is a special case. foreach(i, ref int v; someArray) { // i is size_t } Can you do the following? i = 10; No you can't, cause they aren't the same thing! If you want to stick with that, I can do a case without creating another variable. How do I do that with foreach so I don't have to do this: foreach( i, ref int value; arr ) { int i = cast(int)i; } foreach( int i, ref int value; arr ) { // better }2. I noticed with Windows MovieMaker that it produces corrupt output files if the movie is bigger than 4Gb. Evidently a 32 bit counter isn't enough.1. That's not even remotely related. The error in Movie Maker is caused by the C api (on Windows) uses 32-bit integers. 2. If they were using D and for some reason they wanted to create the entire file in memory first before writing it to a file. There still would have been the same problem. If you build on 32-bit size_t is int, so they would be limited to 4 GB files. Not to mention how horrible it would be on memory, but I know you and DMD love your memory leaks (never running the garbage collector nor freeing the memory used) and not distributing 64-bit binaries, but I'll leave it at that maybe you would fill an entire array before writing it to a file. 3. Creating such a huge array in the first place is just a bad idea. You get incompatibilities with 32-bit and 64-bit, and most of the time you don't need to do it. It's a code smell honestly. You should probably have a structure that specifically deals with gigantic arrays, to disable things like copying the array. Though again you'll almost never need it except for very special cases. 4. I never said to NEVER use a 64-bit integer, merely that you almost never need an array that would fill a 32-bit length (your Movie Maker example has not disproved that). Hell you can make DMD use 32-bit integers for all it's arrays and it will still function even though it runs out of memory (not because it allocates an array that fills 32-bit counter though) because it is one gigantic memory leak. I know it still works with 32-bit cause there is no 64-bit version for Windows! Classic.
Feb 05 2019
On 2/5/2019 1:14 PM, Rubn wrote:WHAT. WHAT. Where do you see an assignment from size_t to int here? int[] arr = someRandomArray(); for( int i = 0; i < arr.length; ++i ) { dg( i, arr[i] ); } ???The ++i overflows and the loop never terminates.
Feb 05 2019
On Tuesday, 5 February 2019 at 23:04:16 UTC, Walter Bright wrote:On 2/5/2019 1:14 PM, Rubn wrote:I'm saying SEMANTICALLY it is correct.WHAT. WHAT. Where do you see an assignment from size_t to int here? int[] arr = someRandomArray(); for( int i = 0; i < arr.length; ++i ) { dg( i, arr[i] ); } ???The ++i overflows and the loop never terminates.
Feb 05 2019
On Tuesday, 5 February 2019 at 23:04:16 UTC, Walter Bright wrote:On 2/5/2019 1:14 PM, Rubn wrote:Just as it is safe. safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } }WHAT. WHAT. Where do you see an assignment from size_t to int here? int[] arr = someRandomArray(); for( int i = 0; i < arr.length; ++i ) { dg( i, arr[i] ); } ???The ++i overflows and the loop never terminates.
Feb 05 2019
On Tuesday, 5 February 2019 at 23:04:16 UTC, Walter Bright wrote:On 2/5/2019 1:14 PM, Rubn wrote:In case you forgot what you said:WHAT. WHAT. Where do you see an assignment from size_t to int here? int[] arr = someRandomArray(); for( int i = 0; i < arr.length; ++i ) { dg( i, arr[i] ); } ???The ++i overflows and the loop never terminates.It's irrelevant, as the semantics of the language have to be sound across the uses it supports.This change to not allow int goes against the semantics of the language.
Feb 05 2019
On Tuesday, 5 February 2019 at 21:14:17 UTC, Rubn wrote:On Tuesday, 5 February 2019 at 04:53:00 UTC, Walter Bright wrote:Memory mapping archives and video files can easily get beyond 32 bits. It's not because you never noticed that there aren't people out there doing that every day.[...]WHAT. WHAT. Where do you see an assignment from size_t to int here? [...][...]
Feb 05 2019
On Wednesday, 6 February 2019 at 06:27:27 UTC, Patrick Schluter wrote:On Tuesday, 5 February 2019 at 21:14:17 UTC, Rubn wrote:I never knew arrays were files, thanks for the tip.On Tuesday, 5 February 2019 at 04:53:00 UTC, Walter Bright wrote:Memory mapping archives and video files can easily get beyond 32 bits. It's not because you never noticed that there aren't people out there doing that every day.[...]WHAT. WHAT. Where do you see an assignment from size_t to int here? [...][...]
Feb 06 2019
On Wed, Feb 06, 2019 at 08:59:14PM +0000, Rubn via Digitalmars-d wrote:On Wednesday, 6 February 2019 at 06:27:27 UTC, Patrick Schluter wrote:[...][...]Memory mapping archives and video files can easily get beyond 32 bits. It's not because you never noticed that there aren't people out there doing that every day.I never knew arrays were files, thanks for the tip.As you may know, mmap() turns files into arrays (see std.mmfile). You access it just like an array, and the OS maps it to the file for you. You wouldn't want somebody to pass the array returned by an mmap() call to your code that assumes arrays cannot have length larger than 32-bits -- you'd run into wraparound bugs. Just because the array has a huge size doesn't necessarily mean you need that much RAM to hold it. The OS pages parts of it in/out as you access it. T -- If blunt statements had a point, they wouldn't be blunt...
Feb 06 2019
On Wednesday, 6 February 2019 at 21:23:20 UTC, H. S. Teoh wrote:[snip] As you may know, mmap() turns files into arrays (see std.mmfile). You access it just like an array, and the OS maps it to the file for you. You wouldn't want somebody to pass the array returned by an mmap() call to your code that assumes arrays cannot have length larger than 32-bits -- you'd run into wraparound bugs. Just because the array has a huge size doesn't necessarily mean you need that much RAM to hold it. The OS pages parts of it in/out as you access it. Tmmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.
Feb 06 2019
On Wed, Feb 06, 2019 at 10:00:35PM +0000, jmh530 via Digitalmars-d wrote: [...]mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.It depends on how big your resident set size is, and what your memory access patterns are. If you're using the mmap'd memory in a random-access pattern, be prepared for your OS to slow down to a crawl as it begins thrashing on I/O swapping pages from disk only to evict them milliseconds later because there's no more memory to load in the page for the next random access. There's no free lunch. :-P That's why in this day and age people are moving away from hashtables, once hailed as the holy grail of data structure design, to structures based on linear access that have "worse" big-O complexity but better real-world performance, because linear access plays nicer with the cache hierarchy. T -- "How are you doing?" "Doing what?"
Feb 06 2019
On Wednesday, 6 February 2019 at 22:29:11 UTC, H. S. Teoh wrote:[snip]Very informative. Thanks.
Feb 06 2019
On 2/6/2019 2:00 PM, jmh530 wrote:mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
Feb 06 2019
On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:On 2/6/2019 2:00 PM, jmh530 wrote:I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
Feb 07 2019
On Thursday, February 7, 2019 4:02:14 PM MST Rubn via Digitalmars-d wrote:On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:If you're trying to say that you think that that's a compiler bug, then you misunderstand safe. safe code cannot access invalid memory. It cannot have undefined behavior. But it can have plenty of logic bugs, and what that code has is a logic bug. It's at zero risk of accessing invalid memory. It's just going to do the wrong thing if the array is sufficiently large. The only way that array size issues are an safe-related bug is if you have code that somehow manages to access the array out-of-bounds in spite of the code being safe. It's been argued before that comparing integer types of different size or signedness should not be legal, because it's a source of bugs, and maybe it shouldn't be legal, but even if that's true, it's still not an issue with safe. - Jonathan M DavisOn 2/6/2019 2:00 PM, jmh530 wrote:I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
Feb 07 2019
On Thursday, 7 February 2019 at 23:37:06 UTC, Jonathan M Davis wrote:On Thursday, February 7, 2019 4:02:14 PM MST Rubn via Digitalmars-d wrote:Good you agree it isn't a bug. Then we should remove this deprecation right?On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:If you're trying to say that you think that that's a compiler bug, then you misunderstand safe. safe code cannot access invalid memory. It cannot have undefined behavior. But it can have plenty of logic bugs, and what that code has is a logic bug. It's at zero risk of accessing invalid memory. It's just going to do the wrong thing if the array is sufficiently large. The only way that array size issues are an safe-related bug is if you have code that somehow manages to access the array out-of-bounds in spite of the code being safe. It's been argued before that comparing integer types of different size or signedness should not be legal, because it's a source of bugs, and maybe it shouldn't be legal, but even if that's true, it's still not an issue with safe. - Jonathan M DavisOn 2/6/2019 2:00 PM, jmh530 wrote:I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
Feb 08 2019
On Friday, February 8, 2019 5:05:09 PM MST Rubn via Digitalmars-d wrote:On Thursday, 7 February 2019 at 23:37:06 UTC, Jonathan M Davis wrote:It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that. - Jonathan M DavisOn Thursday, February 7, 2019 4:02:14 PM MST Rubn via Digitalmars-d wrote:Good you agree it isn't a bug. Then we should remove this deprecation right?On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:If you're trying to say that you think that that's a compiler bug, then you misunderstand safe. safe code cannot access invalid memory. It cannot have undefined behavior. But it can have plenty of logic bugs, and what that code has is a logic bug. It's at zero risk of accessing invalid memory. It's just going to do the wrong thing if the array is sufficiently large. The only way that array size issues are an safe-related bug is if you have code that somehow manages to access the array out-of-bounds in spite of the code being safe. It's been argued before that comparing integer types of different size or signedness should not be legal, because it's a source of bugs, and maybe it shouldn't be legal, but even if that's true, it's still not an issue with safe. - Jonathan M DavisOn 2/6/2019 2:00 PM, jmh530 wrote:I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
Feb 08 2019
On Saturday, 9 February 2019 at 02:13:13 UTC, Jonathan M Davis wrote:On Friday, February 8, 2019 5:05:09 PM MST Rubn via Digitalmars-d wrote:It's a bandaid, the larger problem is allowing the comparison between int and size_t. Which my bet is how it is implemented internally, which is why foreach_reverse doesn't work cause it actually has to assign the counter a size_t.On Thursday, 7 February 2019 at 23:37:06 UTC, Jonathan M Davis wrote:It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that. - Jonathan M DavisOn Thursday, February 7, 2019 4:02:14 PM MST Rubn via Digitalmars-d wrote:Good you agree it isn't a bug. Then we should remove this deprecation right?On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:If you're trying to say that you think that that's a compiler bug, then you misunderstand safe. safe code cannot access invalid memory. It cannot have undefined behavior. But it can have plenty of logic bugs, and what that code has is a logic bug. It's at zero risk of accessing invalid memory. It's just going to do the wrong thing if the array is sufficiently large. The only way that array size issues are an safe-related bug is if you have code that somehow manages to access the array out-of-bounds in spite of the code being safe. It's been argued before that comparing integer types of different size or signedness should not be legal, because it's a source of bugs, and maybe it shouldn't be legal, but even if that's true, it's still not an issue with safe. - Jonathan M DavisOn 2/6/2019 2:00 PM, jmh530 wrote:I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
Feb 12 2019
On Saturday, 9 February 2019 at 02:13:13 UTC, Jonathan M Davis wrote:On Friday, February 8, 2019 5:05:09 PM MST Rubn via Digitalmars-d wrote:The point was, if you don't see the for() being an issue that has to be fixed. Then there's no reason to see foreach() as an issue to fix. You either fix them both or don't, it doesn't make sense to fix one but not the other. foreach()'s implementation is literally just a for() statement which is where the bug originates from.On Thursday, 7 February 2019 at 23:37:06 UTC, Jonathan M Davis wrote:It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that. - Jonathan M DavisOn Thursday, February 7, 2019 4:02:14 PM MST Rubn via Digitalmars-d wrote:Good you agree it isn't a bug. Then we should remove this deprecation right?On Thursday, 7 February 2019 at 03:20:03 UTC, Walter Bright wrote:If you're trying to say that you think that that's a compiler bug, then you misunderstand safe. safe code cannot access invalid memory. It cannot have undefined behavior. But it can have plenty of logic bugs, and what that code has is a logic bug. It's at zero risk of accessing invalid memory. It's just going to do the wrong thing if the array is sufficiently large. The only way that array size issues are an safe-related bug is if you have code that somehow manages to access the array out-of-bounds in spite of the code being safe. It's been argued before that comparing integer types of different size or signedness should not be legal, because it's a source of bugs, and maybe it shouldn't be legal, but even if that's true, it's still not an issue with safe. - Jonathan M DavisOn 2/6/2019 2:00 PM, jmh530 wrote:I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.mmap is something that I never really played around much with, but it seems like it would be useful for me in some cases. I've done some Monte Carlo simulations that end up causing me to run out of memory. Doing it as an mmap instead might be slower but at least I wouldn't run out of memory.Executables are not loaded into memory before running them, they are mmap'ed into memory. Digital Mars C++ used mmap for precompiled headers. There are all kinds of uses, it's a very effective tool.
Feb 12 2019
On Wednesday, 13 February 2019 at 01:54:35 UTC, Rubn wrote:On Saturday, 9 February 2019 at 02:13:13 UTC, Jonathan M DavisThe `for` is an issue, but one that is much harder to reason about. With `foreach` over arrays, the index is going to be used for indexing. With for, the counter (if any) is assigned separately and _may_ be used in an arbitrary stopping condition and the indexing (if any) is in the loop.It's not a compiler bug, but the code is still buggy. Using int for indexing is wrong in the general case. It works for smaller arrays, but it's just a bug waiting to happen. I see no problem with the deprecation. Quite the opposite. Using int when size_t should be used is an incredibly common bug, and this helps combat that. - Jonathan M DavisIt's a bandaid, the larger problem is allowing the comparison between int and size_t. Which my bet is how it is implemented internally, which is why foreach_reverse doesn't work cause it actually has to assign the counter a size_t. The point was, if you don't see the for() being an issue that has to be fixed. Then there's no reason to see foreach() as an issue to fix. You either fix them both or don't, it doesn't make sense to fix one but not the other. foreach()'s implementation is literally just a for() statement which is where the bug originates from.
Feb 12 2019
On Saturday, 9 February 2019 at 00:05:09 UTC, Rubn wrote:Good you agree it isn't a bug. Then we should remove this deprecation right?The entire ecosystem is locked on unsigned integers, you can't just pull them out.
Feb 18 2019
On Monday, 18 February 2019 at 11:43:11 UTC, Kagamin wrote:On Saturday, 9 February 2019 at 00:05:09 UTC, Rubn wrote:This feature is currently in DMD, and they are breaking code to change the behavior to not include it. I have no idea what you are talking about.Good you agree it isn't a bug. Then we should remove this deprecation right?The entire ecosystem is locked on unsigned integers, you can't just pull them out.
Feb 18 2019
On 2/7/2019 3:02 PM, Rubn wrote:[...] classic.Use of such words will result in deletion of the posts. Please use professional demeanor on these forums.
Feb 07 2019
On Friday, 8 February 2019 at 06:33:00 UTC, Walter Bright wrote:On 2/7/2019 3:02 PM, Rubn wrote:You can go ahead and delete the post if you want. It'd be no different than not answer a valid question :), thought maybe mildly better.[...] classic.Use of such words will result in deletion of the posts. Please use professional demeanor on these forums.
Feb 08 2019
On Thursday, 7 February 2019 at 23:02:14 UTC, Rubn wrote:I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.Its not a bug. In the case that a.length > int.max, the loop will not terminate and only print indices. If the loop was for(int i = 0; i < a.length; ++i ) { writeln( a[i] ); } it would still be safe, but the program would crash because the index would (eventually) be OOB. If a.length > uint.max and the loop was for(uint i = 0; i < a.length; ++i ) { writeln( a[i] ); } then the loop fail to terminate, and it would still be safe. All the above problems are avoided using size_t as the index.
Feb 08 2019
On Friday, 8 February 2019 at 08:06:39 UTC, Nicholas Wilson wrote:On Thursday, 7 February 2019 at 23:02:14 UTC, Rubn wrote:TIL infinite loop that freezes program isn't a bug.I'll take that to mean you don't think this is a bug: safe void foo(int[] a) { for(int i = 0; i < a.length; ++i ) { writeln( i ); } } Fucking classic.Its not a bug. In the case that a.length > int.max, the loop will not terminate and only print indices. If the loop was for(int i = 0; i < a.length; ++i ) { writeln( a[i] ); } it would still be safe, but the program would crash because the index would (eventually) be OOB. If a.length > uint.max and the loop was for(uint i = 0; i < a.length; ++i ) { writeln( a[i] ); } then the loop fail to terminate, and it would still be safe. All the above problems are avoided using size_t as the index.
Feb 08 2019
On Saturday, 9 February 2019 at 00:15:41 UTC, Rubn wrote:On Friday, 8 February 2019 at 08:06:39 UTC, Nicholas Wilson wrote:It is a bug in your code, not the safe.On Thursday, 7 February 2019 at 23:02:14 UTC, Rubn wrote:TIL infinite loop that freezes program isn't a bug.[...]Its not a bug. In the case that a.length > int.max, the loop will not terminate and only print indices. If the loop was for(int i = 0; i < a.length; ++i ) { writeln( a[i] ); } it would still be safe, but the program would crash because the index would (eventually) be OOB. If a.length > uint.max and the loop was for(uint i = 0; i < a.length; ++i ) { writeln( a[i] ); } then the loop fail to terminate, and it would still be safe. All the above problems are avoided using size_t as the index.
Feb 08 2019
On Thursday, 7 February 2019 at 23:02:14 UTC, Rubn wrote:Fucking classic.Specific language aside, there's a proper way to bring bugs to a maintainer's attention, and telling them "Oh, so you don't think [this bug I hate] is important enough for you? Typical..." out of nowhere is not it. The maintainers have a responsibility to the community, not to you personally. Acting passive-aggressive because they haven't yet fixed your pet issue is incredibly entitled and unprofessional. Please don't. That kind of behavior is common, but it's *not* acceptable.
Feb 08 2019
On Friday, 8 February 2019 at 20:22:29 UTC, Olivier FAURE wrote:The maintainers have a responsibility to the community, not to you personally.Guess you weren't around, Walter's opinion on the matter is they have responsibility to ducking no one.
Feb 08 2019
On Saturday, 9 February 2019 at 00:12:47 UTC, Rubn wrote:On Friday, 8 February 2019 at 20:22:29 UTC, Olivier FAURE wrote:Regardless. Your answers in this thread don't need to be this aggressive. Just because people don't agree with you on how to address an issue doesn't mean you have to patronize them.The maintainers have a responsibility to the community, not to you personally.Guess you weren't around, Walter's opinion on the matter is they have responsibility to ducking no one.
Feb 14 2019
On Wednesday, 6 February 2019 at 21:23:20 UTC, H. S. Teoh wrote:On Wed, Feb 06, 2019 at 08:59:14PM +0000, Rubn via Digitalmars-d wrote:Not everyone is writing generic code. Especially in performance critical code. Like I was saying, this is one those very rare use cases anyways. And AGAIN if you have a memory mapped file in a 32-bit executable, this will not function. Lol man the implementation of mmfile. The interface all uses ulong but then it casts everything to size_t, that's a minefield on a 32-bit system. Good luck accessing a > 4GB file with that.On Wednesday, 6 February 2019 at 06:27:27 UTC, Patrick Schluter wrote:[...][...]Memory mapping archives and video files can easily get beyond 32 bits. It's not because you never noticed that there aren't people out there doing that every day.I never knew arrays were files, thanks for the tip.As you may know, mmap() turns files into arrays (see std.mmfile). You access it just like an array, and the OS maps it to the file for you. You wouldn't want somebody to pass the array returned by an mmap() call to your code that assumes arrays cannot have length larger than 32-bits -- you'd run into wraparound bugs.Just because the array has a huge size doesn't necessarily mean you need that much RAM to hold it. The OS pages parts of it in/out as you access it.Which will be extremely slow. That might be fine for testing something but you'll be better off writing your own code to handle processing that much data in a way that is most efficient for whatever it is you are doing.
Feb 06 2019
On Tuesday, 5 February 2019 at 21:14:17 UTC, Rubn wrote:On Tuesday, 5 February 2019 at 04:53:00 UTC, Walter Bright wrote:Seems that the size_t would have to be a compiler variable we don't see, but would be nice to have this answered.I.e. where the array bounds are known at compile time, then it works, because: enum long l = 3; uint i = l; also works.WHAT. WHAT. Where do you see an assignment from size_t to int here? int[] arr = someRandomArray(); for( int i = 0; i < arr.length; ++i ) { dg( i, arr[i] ); } ???
Feb 06 2019
On Tuesday, 5 February 2019 at 03:15:03 UTC, Timon Gehr wrote:I wish it wasn't. It seems this doesn't do anything usefulIt does! Even I, who contribute only occasionally, have more than once submitted a PR to Phobos that passes my local 32-bit tests, but fails on the GitHub autotester. And the reason is precisely because I tend to accidently assign size_t to int or uint. With this change, I can now immediately detect when I make that error, and I don't think I'm the only 32-bit user who makes them.
Feb 05 2019
On Tuesday, 5 February 2019 at 11:53:13 UTC, Dukc wrote:With this change, I can now immediately detect when I make that error, and I don't think I'm the only 32-bit user who makes them.In one of my first D program I used `int` to store some index or something. First time trying -m64 broke everything then... - Elias
Feb 05 2019
On Tuesday, 5 February 2019 at 11:53:13 UTC, Dukc wrote:On Tuesday, 5 February 2019 at 03:15:03 UTC, Timon Gehr wrote:Nope this will still work on 32-bit: foreach(uint i, ref int value; arr ) { } size_t is just an alias for uint on 32-bit and ulong on 64-bit.I wish it wasn't. It seems this doesn't do anything usefulIt does! Even I, who contribute only occasionally, have more than once submitted a PR to Phobos that passes my local 32-bit tests, but fails on the GitHub autotester. And the reason is precisely because I tend to accidently assign size_t to int or uint. With this change, I can now immediately detect when I make that error, and I don't think I'm the only 32-bit user who makes them.
Feb 05 2019
On Tuesday, 5 February 2019 at 21:16:12 UTC, Rubn wrote:Nope this will still work on 32-bit: foreach(uint i, ref int value; arr ) { } size_t is just an alias for uint on 32-bit and ulong on 64-bit.If so, too bad. But it'll still help, because if I try to compile to 64-bit, the compiler will catch the error. Without the deprecation, there would be a bug (due to 32-bit overflow) that likely never manifests, but bites all the harder if it still does.
Feb 05 2019
On Tuesday, 5 February 2019 at 21:51:41 UTC, Dukc wrote:If so, too bad. But it'll still help, because if I try to compile to 64-bit, the compiler will catch the error. Without the deprecation, there would be a bug (due to 32-bit overflow) that likely never manifests, but bites all the harder if it still does.There's no limit to error checks, do you compile with warnings enabled? See https://dlang.org/articles/warnings.html
Feb 06 2019