This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v1 02/36] Guile extension language: doc additions
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 04 Jan 2014 12:57:21 +0100
- Subject: Re: [PATCH v1 02/36] Guile extension language: doc additions
- Authentication-results: sourceware.org; auth=none
- References: <52b9da59 dot 64ab440a dot 0b0b dot 7e1c at mx dot google dot com> <83ha9w68av dot fsf at gnu dot org> <87sit4kb1t dot fsf at gnu dot org> <83eh4ow78t dot fsf at gnu dot org>
Eli Zaretskii <eliz@gnu.org> skribis:
>> >> +@defun value? object
>>
>> What about distinguishing Scheme functions, like:
>>
>> @deffn {Scheme Procedure} value? object
>
> If it's important (is it?), then yes.
I think I would find it clearer, to someone who skims over the manual.
>> >> +If @var{type} is not provided,
>> >> +a Scheme real is converted to the C @code{double} type for the
>> >> +current architecture.
>> >
>> > Isn't Guile built with libgmp? If so, doesn't it support floats
>> > which, when converted to a double, will lose accuracy?
>>
>> Guile uses GMP, but GMP is for integers (bignums).
>
> What about long double support?
Guile doesnât support it out of the box.
If needed, it could easily be implemented as an extension: one would use
a SMOB to wrap long doubles and pass them to Scheme, and possibly define
methods for â+â, â-â, etc. for objects of this type.
Of course, this wouldnât be terribly efficient, but thatâs not so
important here I think; what matters is that it would allow âlong
doubleâ values to be passed around without loss of accuracy.
That said, my feeling is that leaving things as is (with long doubles
cast to doubles) may prove to be sufficient for most practical uses of
GDB.
WDYT?
>> >> +A Scheme string is converted to a target string, using the current
>> >> +target encoding.
>> >
>> > What if target encoding doesn't support some of the characters in the
>> > string?
>>
>> Guileâs behavior can be controlled with
>> â%default-port-conversion-strategyâ: it can raise an exception, or
>> substitute any characters that could not be converted, or escape them
>> (info "(guile) Ports").
>>
>> Perhaps this should be briefly mentioned, with a cross-ref.
>
> It should, because the issue will certainly arise, especially since
> (AFAIU) Guile prefers UTF-8.
Right. (UTF-8 is just the default encoding for source code; itâs not
âpreferredâ in any other way.)
>> >> +If the optional @var{length} argument is given, the string will be
>> >> +fetched and encoded to the length of characters specified. If
>> >> +the @var{length} argument is not provided, the string will be fetched
>> >> +and encoded until a null of appropriate width is found.
>> >
>> > Isn't this null termination description skewed towards C-like
>> > languages? Aren't there languages where strings don't have to be
>> > null-terminated?
>>
>> Yes, and thatâs when LENGTH should be provided, AIUI.
>
> Then I guess the above should say that explicitly. But it would be
> nice if GDB could support strings in languages that don't
> null-terminate even without LENGTH.
Agreed (I had misread the description above as saying that, if LENGTH is
provided, then the string is *not* assumed to be nul-terminated.)
Thanks,
Ludoâ.