I guess I still question why you are not just calling yy_scan_bytes. If
you look at the output of flex it contains the source code for
yy_scan_bytes, which shows it doing *exactly* the same thing (allocating
a buffer 2 bytes larger, copying the memory block, setting the nulls,
then calling yy_s
Hi Ran
On Thu, Mar 14, 2013 at 2:14 PM, Ran Benita wrote:
> On Wed, Mar 13, 2013 at 07:28:17PM +0200, Ran Benita wrote:
>> On Mon, Mar 11, 2013 at 12:53:39PM +0100, David Herrmann wrote:
>> > The current API doesn't allow the caller to create keymaps from mmap()'ed
>> > files. The problem is, xkb
On Wed, Mar 13, 2013 at 07:28:17PM +0200, Ran Benita wrote:
> On Mon, Mar 11, 2013 at 12:53:39PM +0100, David Herrmann wrote:
> > The current API doesn't allow the caller to create keymaps from mmap()'ed
> > files. The problem is, xkb_keymap_new_from_string() requires a terminating
> > 0 byte. Howe
On Mon, Mar 11, 2013 at 12:53:39PM +0100, David Herrmann wrote:
> The current API doesn't allow the caller to create keymaps from mmap()'ed
> files. The problem is, xkb_keymap_new_from_string() requires a terminating
> 0 byte. However, there is no way to guarantee that when using mmap() so a
> user
Hi Bill
On Mon, Mar 11, 2013 at 7:06 PM, Bill Spitzak wrote:
> Okay looking more at your patch and the output of flex, I think you can just
> call yy_scan_bytes. It does a copy, true, but that is exactly what your code
> is doing. And it does it by reusing code that is already in the flex output.
Okay looking more at your patch and the output of flex, I think you can
just call yy_scan_bytes. It does a copy, true, but that is exactly what
your code is doing. And it does it by reusing code that is already in
the flex output.
And if flex is ever fixed so the two nulls are not needed, it s
Oops, never mind, it looks like you have already analyzed yy_scan_byte
and found it calls yy_scan_buffer internally (!!!). Oh well.
David Herrmann wrote:
Internally, we depend on yy_scan_{string,byte}() helpers. According to
flex documentation these already copy the input string because they a
I know we got flex to work without a terminating null. A quick look at
the source code reveals that we are calling this:
yy_scan_bytes(buffer, length, scanner);
Our code also does this:
#define YY_INPUT(a,b,c) // disable read-next-buffer: unused and makes a
warning
I'm not sure if t
The current API doesn't allow the caller to create keymaps from mmap()'ed
files. The problem is, xkb_keymap_new_from_string() requires a terminating
0 byte. However, there is no way to guarantee that when using mmap() so a
user currently has to copy the whole file just to get the terminating zero
b
