public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <xdje42@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH v1 02/36] Guile extension language: doc additions
Date: Sun, 19 Jan 2014 21:19:00 -0000	[thread overview]
Message-ID: <CAP9bCMQCe5NJ7+yOS8d8LHsnNEZaKP5SR3rH9i0PAdg21-300Q@mail.gmail.com> (raw)
In-Reply-To: <83sisjj105.fsf@gnu.org>

On Sun, Jan 19, 2014 at 10:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 19 Jan 2014 09:53:21 -0800
>> From: Doug Evans <xdje42@gmail.com>
>> Cc: Ludovic Courtès <ludo@gnu.org>,
>>       "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> >   For C-like languages, a value is a string if it is a pointer to or an
>> >   array of characters or ints of type @code{wchar_t}, @code{char16_t},
>> >   or @code{char32_t}.  For other languages ... [say here how string
>> >   values are distinguished in other languages].  If the string is
>> >   terminated by a zero of the appropriate width, it will be converted up
>> >   to that zero.  For strings that are not zero-terminated (which
>> >   includes strings in non C-like languages), you must specify the length
>> >   for conversion.
>>
>> Even in C-like languages the user may wish to specify a length.
>>
>> E.g., C++ strings have a length, but it's up to the library to specify how it's
>> recorded.  Plus C++ programs can have multiple string implementations
>> (not just std::string).  Not always ideal, but an app may have a specific
>> performance issue for a specific part of it and thus provides its own
>> string implementation for that part.  Thus in this (important) case there
>> is no text I can provide here to answer the question you are asking.
>>
>> Plus there's a maintenance issue of describing how each language
>> defines a string.  We don't want to have to update this part for each
>> new language.
>
> Fair enough.  How about the following variant, which is entirely
> agnostic to the language?
>
>   Values are interpreted as strings according to the rules of the
>   current language.  If the optional length argument is given, the
>   string will be converted to that length.  Otherwise, for languages
>   where the string is zero-terminated, the entire string will be
>   converted.
>
> If you want to say something about C-like languages, we can have a
> "for example" sentence after the 1st one.  Something like
>
>   For example, in C-like languages, a value is a string if it is a
>   pointer to, or an array of, characters or ints of type ...
>
>> Please can I keep the current text?
>
> If you think it is better than what I suggested above.

I tweaked it a bit because I wanted to make clear specifying the
length will include any embedded zeroes.

Values are interpreted as strings according to the rules of the
current language.  If the optional length argument is given, the
string will be converted to that length, and will include any embedded
zeroes that the string may contain.  Otherwise, for languages
where the string is zero-terminated, the entire string will be
converted.

For example, in C-like languages, a value is a string if it is a pointer
to or an array of characters or ints of type @code{wchar_t}, @code{char16_t},
or @code{char32_t}.

  reply	other threads:[~2014-01-19 21:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-24 19:03 Doug Evans
2013-12-25 19:27 ` Eli Zaretskii
2014-01-03 21:31   ` Ludovic Courtès
2014-01-04  7:12     ` Eli Zaretskii
2014-01-04 11:57       ` Ludovic Courtès
2014-01-04 14:41         ` Eli Zaretskii
2014-01-04 17:42           ` Ludovic Courtès
2014-01-04 20:00             ` Eli Zaretskii
2014-01-16  4:20               ` Doug Evans
2014-01-18 20:36         ` Doug Evans
2014-01-18 20:52           ` Ludovic Courtès
2014-01-18 20:55             ` Doug Evans
2014-01-19 16:58               ` Eli Zaretskii
2014-01-19 17:19                 ` Doug Evans
2014-01-19 17:34                   ` Eli Zaretskii
2014-01-19 17:53                     ` Doug Evans
2014-01-19 18:10                       ` Eli Zaretskii
2014-01-19 21:19                         ` Doug Evans [this message]
2014-01-18 20:16     ` Doug Evans
2014-01-18 20:42       ` Ludovic Courtès
2014-01-18 21:57         ` Doug Evans
2014-01-19 14:46           ` Ludovic Courtès
2014-01-19 21:37             ` Doug Evans
2014-01-19 22:50               ` Ludovic Courtès
2014-01-18 22:32     ` Doug Evans
2014-01-19 14:47       ` Ludovic Courtès
2014-01-19 15:56         ` Eli Zaretskii
2014-01-19 16:13           ` Ludovic Courtès
2014-01-19 17:05             ` Doug Evans
2014-01-18 20:06   ` Doug Evans
2014-01-18 20:24     ` Eli Zaretskii
2014-01-18 20:53       ` Doug Evans
2014-01-19 16:57         ` Eli Zaretskii
2014-01-19 17:42           ` Doug Evans
2014-01-19 21:01           ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAP9bCMQCe5NJ7+yOS8d8LHsnNEZaKP5SR3rH9i0PAdg21-300Q@mail.gmail.com \
    --to=xdje42@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).