On Wednesday, 20 September 2017 at 10:01:14 UTC, Kagamin wrote:
On Monday, 18 September 2017 at 17:46:52 UTC, Ola Fosheim
Grøstad wrote:
No, I don't believe they do, as unsigned integers are modular
in C/C++.
So you can't check third party code because it pervasively uses
unsigned integers
On Monday, 18 September 2017 at 17:46:52 UTC, Ola Fosheim Grøstad
wrote:
No, I don't believe they do, as unsigned integers are modular
in C/C++.
So you can't check third party code because it pervasively uses
unsigned integers for lengths, sizes and everything else, obvious
example:
On Monday, September 18, 2017 22:39:09 Moritz Maxeiner via Digitalmars-d
wrote:
> On Monday, 18 September 2017 at 22:32:28 UTC, Dennis Cote wrote:
> > On Monday, 18 September 2017 at 13:25:55 UTC, Andrei
> >
> > Alexandrescu wrote:
> >> For the record, with the help of
On Monday, 18 September 2017 at 22:32:28 UTC, Dennis Cote wrote:
On Monday, 18 September 2017 at 13:25:55 UTC, Andrei
Alexandrescu wrote:
For the record, with the help of std.experimental.checkedint,
the change that fixes the code would be:
malloc(width * height * 4) ==>
On Monday, 18 September 2017 at 13:25:55 UTC, Andrei Alexandrescu
wrote:
For the record, with the help of std.experimental.checkedint,
the change that fixes the code would be:
malloc(width * height * 4) ==> malloc((checked(width) * height
* 4).get)
That aborts the application with a message
On Monday, 18 September 2017 at 11:42:19 UTC, Kagamin wrote:
Do they check unsigned integers?
No, I don't believe they do, as unsigned integers are modular in
C/C++. (And in D also signed integers are modular).
On Monday, 18 September 2017 at 14:36:35 UTC, Jonathan M Davis
wrote:
We have std.experimental.checkedint, so why would there be any
need for it to be in the compiler? The library solution
provides the functionality and does so in a much more flexible
manner than the compiler reasonably could.
On Monday, September 18, 2017 08:35:44 Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis
>
> wrote:
> > There also really isn't a need to do so.
>
> If there was no need then C/C++ compilers wouldn't provide it as
> an option…
We have
On 09/15/2017 04:46 AM, Guillaume Piolat wrote:
As a die-hard native programmer I was always disgusted by integer
overflow checks and array bounds checks. Littering code with branches
everywhere? Just let me go as fast possible please!
Last week I was explained by security people how a part
On Monday, 18 September 2017 at 08:35:44 UTC, Ola Fosheim Grøstad
wrote:
If there was no need then C/C++ compilers wouldn't provide it
as an option…
Do they check unsigned integers?
On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis
wrote:
If you care about having the overflow checks
On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis
wrote:
Personally, I've never had a need for checked ints. I've rarely
seen code that would care, and when you
On Monday, 18 September 2017 at 08:27:21 UTC, Jonathan M Davis
wrote:
There also really isn't a need to do so.
If there was no need then C/C++ compilers wouldn't provide it as
an option…
On Friday, September 15, 2017 19:01:18 Walter Bright via Digitalmars-d
wrote:
> On 9/15/2017 5:00 PM, bitwise wrote:
> > On Friday, 15 September 2017 at 21:21:01 UTC, Walter Bright wrote:
> >> https://dlang.org/phobos/std_experimental_checkedint.html
> >
> > Will this ever be integrated directly
On 9/16/2017 2:55 AM, Walter Bright wrote:
The programming community is coming around, very slowly, to what the airframe
industry learned generations ago. I.e. you *never* rely on people in the system
not making mistakes.
The Equifax disaster is another lesson the airframe industry learned
On 9/15/2017 9:39 AM, Kagamin wrote:
It's not because nobody knows about buffer overflows. C leaves the task on the
programmer, and the task is too huge for manual labor without help from the
language, ecosystem and coding practices, of course nobody does it.
The problem with C is that it
On 9/15/2017 5:00 PM, bitwise wrote:
On Friday, 15 September 2017 at 21:21:01 UTC, Walter Bright wrote:
https://dlang.org/phobos/std_experimental_checkedint.html
Will this ever be integrated directly into the compiler?
No plans to do so.
On Friday, 15 September 2017 at 21:21:01 UTC, Walter Bright wrote:
On 9/15/2017 1:46 AM, Guillaume Piolat wrote:
If overflow checks happen to be more or less cheap like
(surprinsingly) array bounds checks are, it could be a nice
thing to pay for.
On 9/15/2017 1:46 AM, Guillaume Piolat wrote:
If overflow checks happen to be more or less cheap like (surprinsingly) array
bounds checks are, it could be a nice thing to pay for.
https://dlang.org/phobos/std_experimental_checkedint.html
Point taken about proper allocator with returned size. It's
indeed a minority of cases in regular D.
On Friday, 15 September 2017 at 16:39:46 UTC, Kagamin wrote:
It's not because nobody knows about buffer overflows. C leaves
the task on the programmer, and the task is too huge for manual
On Friday, 15 September 2017 at 16:04:08 UTC, Neia Neutuladh
wrote:
The last solution that I can think of, specific to this type of
thing, is to use the result to allocate a bounds-checked array,
where the allocation function yields the appropriately sized
array. You'll get an array bounds
On Friday, 15 September 2017 at 12:25:10 UTC, Guillaume Piolat
wrote:
Well here I don't think so: this attack is used to adress a
very large space, while having a very small actually allocated
memory space. Bounds would be too large to matter.
As long as it works in bounds it should be more
On Friday, 15 September 2017 at 12:33:56 UTC, Adam D. Ruppe wrote:
On Friday, 15 September 2017 at 12:04:27 UTC, Kagamin wrote:
Since width can't be negative, C programmer would use unsigned
integer for it
That's often a big mistake. Lots of people do it... but you
shouldn't, exactly because
On Friday, 15 September 2017 at 12:04:27 UTC, Kagamin wrote:
Since width can't be negative, C programmer would use unsigned
integer for it
That's often a big mistake. Lots of people do it... but you
shouldn't, exactly because of the wraparound behavior.
would normally be prevented by bound checks
in case of integer overflow.
Well here I don't think so: this attack is used to adress a very
large space, while having a very small actually allocated memory
space. Bounds would be too large to matter.
have a safer wrapper around malloc in your
overflow would normally be prevented by bound
checks in case of integer overflow. Just have a safer wrapper
around malloc in your example.
As a die-hard native programmer I was always disgusted by integer
overflow checks and array bounds checks. Littering code with
branches everywhere? Just let me go as fast possible please!
Last week I was explained by security people how a part of
vulnerabilities todays are attacks on image
26 matches
Mail list logo
