[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/3] scratch_buffer: new module

From: Paul Eggert
Subject: Re: [PATCH 2/3] scratch_buffer: new module
Date: Sat, 2 Sep 2017 14:39:39 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 09/02/2017 02:11 AM, Paul Eggert wrote:

struct scratch_buffer depends on a GNU C extension:
assignment to an object changes its dynamic type.  It is not standard C.
  Standard C only allows one way to allocate untyped memory, and that is

That should not be a problem, as Gnulib code regularly breaks those standard-C rules when it comes to memory allocation.

in looking at the current Gnulib glob.c again, my previous email was too pessimistic. Gnulib glob.c accesses the stack-allocated objects in question only via char * pointers, and standard C (C11 section 6.5 paragraph 7 last line) has an exception for these accesses that makes the glob.c code valid. So we should be OK even on theoretical platforms that insist on strict conformance here.

Here's the Gnulib commit that the above analysis refers to:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]