emacs-devel
[Top][All Lists]
Advanced

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

Re: [RFC] temporary Lisp_Strings


From: Andreas Schwab
Subject: Re: [RFC] temporary Lisp_Strings
Date: Tue, 02 Sep 2014 15:21:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Dmitry Antipov <address@hidden> writes:

> I'm thinking about temporary Lisp_Strings on C stack (allocated with alloca).
> Simple implementation (with no check whether it fits on stack) and a few use
> cases attached.  Among others, the question is: is there a way to make sure
> that an address returned by alloca fits in Lisp_Object?

There is none.  The stack could be in a completely different address
region that may not be suitable in non-USE_LSB_TAG configurations.

> +#define alloca_string(str)                                   \
> +  ({ Lisp_Object string;                                     \
> +     struct Lisp_String *s;                                  \
> +     ptrdiff_t nchars, nbytes, size = strlen (str);          \
> +     parse_str_as_multibyte ((const unsigned char *) str,    \
> +                          size, &nchars, &nbytes);           \
> +     s = alloca (sizeof *s + nbytes + 1);                    \
> +     s->data = (unsigned char *) s + sizeof (*s);            \
> +     memcpy (s->data, str, nbytes);                          \
> +     s->data[size] = '\0';                                   \
> +     s->intervals = NULL;                                    \
> +     if (nbytes == nchars || nbytes != size)                 \
> +       s->size = size, s->size_byte = -1;                    \
> +     else                                                    \
> +       s->size = nchars, s->size_byte = nbytes;              \
> +     XSETSTRING (string, s); string; })

This will eventually fail with USE_LSB_TAG, since you don't enforce
alignment.

Andreas.

-- 
Andreas Schwab, SUSE Labs, address@hidden
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



reply via email to

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