On 12/29/19 11:03 AM, Tim Rühsen wrote:
> A quick web search didn't give me any complaints about immutable in D.
> Do you have some examples or can you elaborate a bit ?
Sorry, I don't recall the details. But the basic problem I had was that the
const/mutable/in trichotomy is kinda complicated. Pa
On 27.12.19 11:51, Bruno Haible wrote:
> Aga wrote:
>> I do not know if
>> you can (or if it is possible, how it can be done), extract with a way a
>> specific
>> a functionality from gnulib, with the absolute necessary code and only that.
>
> gnulib-tool does this. With its --avoid option, the d
On Sun, Dec 29, at 10:19 Bruno Haible wrote:
> Aga wrote:
> > - the returned value of the *printf family of functions dictates their
> > limits/range, as they return an int, this can be as INT_MAX mostly
>
> Yes, we need new implementations of the *asprintf functions that are not
> limited t
On 29.12.19 19:49, Paul Eggert wrote:
> On 12/29/19 4:07 AM, Tim Rühsen wrote:
>> Introducing a stronger 'const' could be helpful in some situations
>
> D has 'immutable' for that. It doesn't work as well as one might think.
It all depends on the implementation / definition of 'immutable' and how
On 12/29/19 4:07 AM, Tim Rühsen wrote:
> Introducing a stronger 'const' could be helpful in some situations
D has 'immutable' for that. It doesn't work as well as one might think.
On Sun, Dec 29, at 10:19 Bruno Haible wrote:
> I agree with the goal. How to do it precisely, is an art however.
Ok, let's see what do we have until now.
First the Base: (easy) that is malloc maximum requested size from the kernel,
and that is PTRDIFF_MAX. We also here we have to forget SIZE_MAX
On 29.12.19 10:45, Bruno Haible wrote:
> Tim Rühsen wrote:
>> the use cases are mostly in the testing area (especially fuzzing).
>
> Indeed. During fuzzing, you want to check against any kind of buggy/undefined
> behaviour, and writing into arbitrary memory is one of these kinds.
>
> This brings
Tim Rühsen wrote:
> the use cases are mostly in the testing area (especially fuzzing).
Indeed. During fuzzing, you want to check against any kind of buggy/undefined
behaviour, and writing into arbitrary memory is one of these kinds.
This brings up the question: Should such as facility be in a San
Ben Pfaff wrote:
> This sort of thing won't work on systems with virtually indexed caches,
> at least not without inserting explicit flushes.
Good point. Yes, explicit data cache flushing instructions or - in the worst
case - system calls are necessary.
> I don't know whether
> virtually indexed
Aga wrote:
> - the returned value of the *printf family of functions dictates their
> limits/range, as they return an int, this can be as INT_MAX mostly
Yes, we need new implementations of the *asprintf functions that are not
limited to returning strings of maximum length INT_MAX.
> - as
10 matches
Mail list logo
