I'm not someone who thinks VLAs are automatically bad and unlike Linux
kernel code they can sometimes be used safely in userspace. However
for an internet exposed server there is an argument that they might
cause some kind of exploitable situation especially if the code is
compiled without other
On 9/5/19 2:40 AM, Richard W.M. Jones wrote:
> I have one comment unrelated to the patch:
>
>> + "set_request_structured_replies", {
>> +default_call with
>> +args = [Bool "request"]; ret = RErr;
>> +permitted_states = [ Created ];
>> +first_version = (1, 2);
>
> I just know
See discussion in this and following messages:
https://www.redhat.com/archives/libguestfs/2019-September/msg00020.html
---
generator/generator | 131
1 file changed, 121 insertions(+), 10 deletions(-)
diff --git a/generator/generator
This doesn't include Eric's new APIs, but if you push those
then I can rebase this one on top.
Rich.
___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
On Thu, Sep 05, 2019 at 07:57:44AM -0500, Eric Blake wrote:
> On 9/5/19 6:28 AM, Richard W.M. Jones wrote:
> > I'm not someone who thinks VLAs are automatically bad and unlike Linux
> > kernel code they can sometimes be used safely in userspace. However
> > for an internet exposed server there is
On 9/5/19 6:38 AM, Richard W.M. Jones wrote:
> Since we don't know much about the calling environment, which might
> have a limited stack, might be taking input from untrusted sources, or
> we might not have other stack protections enabled, it's best to be
> cautious about using unbounded stack
On 9/5/19 6:28 AM, Richard W.M. Jones wrote:
> I'm not someone who thinks VLAs are automatically bad and unlike Linux
> kernel code they can sometimes be used safely in userspace. However
> for an internet exposed server there is an argument that they might
> cause some kind of exploitable
Since we don't know much about the calling environment, which might
have a limited stack, might be taking input from untrusted sources, or
we might not have other stack protections enabled, it's best to be
cautious about using unbounded stack allocations.
We're not in fact using them in libnbd,
On Thu, Sep 05, 2019 at 08:02:34AM -0500, Eric Blake wrote:
> On 9/5/19 6:56 AM, Richard W.M. Jones wrote:
> > See discussion in this and following messages:
> > https://www.redhat.com/archives/libguestfs/2019-September/msg00020.html
> > ---
> > generator/generator | 131
On 9/5/19 6:56 AM, Richard W.M. Jones wrote:
> This doesn't include Eric's new APIs, but if you push those
> then I can rebase this one on top.
Looks good, and my new API is in.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org |
On 9/5/19 6:56 AM, Richard W.M. Jones wrote:
> See discussion in this and following messages:
> https://www.redhat.com/archives/libguestfs/2019-September/msg00020.html
> ---
> generator/generator | 131
> 1 file changed, 121 insertions(+), 10
With OCaml >= 4.09 caml_named_value() returns a const value *, so keep
the constness to build also in this case.
---
common/mlpcre/pcre-c.c | 2 +-
common/mltools/uri-c.c | 2 +-
common/mlvisit/visit-c.c | 2 +-
generator/daemon.ml | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
This is a simple fix for building also with the upcoming OCaml 4.09,
which has a slight API change in the C library.
This does not cover embedded copies such as ocaml-augeas, and
ocaml-libvirt, which are being fixed separately, and will then be
synchronized.
Pino Toscano (1):
ocaml: make const
On Thu, Sep 05, 2019 at 10:47:42AM +0200, Pino Toscano wrote:
> With OCaml >= 4.09 caml_named_value() returns a const value *, so keep
> the constness to build also in this case.
> ---
> common/mlpcre/pcre-c.c | 2 +-
> common/mltools/uri-c.c | 2 +-
> common/mlvisit/visit-c.c | 2 +-
>
In OCaml >= 4.09 the return value pointer of caml_named_value is
declared const.
Based on Pino Toscano's original patch to ocaml-augeas.
---
common/mlpcre/pcre-c.c | 3 +--
common/mltools/uri-c.c | 6 ++
common/mlvisit/visit-c.c | 4 +---
generator/daemon.ml | 2 +-
4 files changed,
On Thursday, 5 September 2019 10:58:41 CEST Richard W.M. Jones wrote:
> In OCaml >= 4.09 the return value pointer of caml_named_value is
> declared const.
>
> Based on Pino Toscano's original patch to ocaml-augeas.
> ---
> common/mlpcre/pcre-c.c | 3 +--
> common/mltools/uri-c.c | 6 ++
>
On Wed, Sep 04, 2019 at 01:28:08PM -0500, Eric Blake wrote:
> We want to default to requesting structured replies, whether or not
> that request will be honored (it's essential for efficient sparse file
> reads and the DF flag for structured pread, as well as for meta
> context support even if we
17 matches
Mail list logo
