View mode: basic / threaded / horizontal-split · Log in · Help
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On 10/1/2012 7:22 PM, Steven Schveighoffer wrote:
> However, we can't require an import to use a bizarre
> specifier, and you can't link un@safe code to a specifier, so the zstr
> concept is far superior in requiring the user to know what he is doing,
> and having the compiler enforce that.

Yup.


> Does it make sense for Phobos to provide such a shortcut in an obscure
> header somewhere? Like std.cstring? Or should we just say "roll your own
> if you need it"?

As a matter of principle, I really don't like gobs of Phobos functions 
that are literally one liners. Phobos should not become a mile wide but 
inch deep library of trivia. It should consist of non-trivial, useful, 
and relatively deep functions.
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
Andrej Mitrovic wrote:
> On 10/1/12, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:
>> For example C binding writers may change:
>>
>> extern(C) char* getstr();
>>
>> to
>>
>> extern(C) cstring getstr();
>
> I don't think you can reliably do that because of semantics w.r.t.
> passing parameters on the stack vs in registers based on whether a
> type is a pointer or not. I've had this sort of bug when wrapping C++
> where the C++ compiler was passing a parameter in one way but the D
> compiler expected the parameters to be passed, simply because I tried
> to be clever and fake a return type. See:
> http://forum.dlang.org/thread/mailman.1547.1346632732.31962.d.gnu@puremagic.com#post-mailman.1557.1346690320.31962.d.gnu:40puremagic.com

I think that align(1) structs that wrap a single value should be treated 
as its type. After all they have the same size and representation. I 
don't know how this works now, though.
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On 10/2/12 4:09 AM, Walter Bright wrote:
> On 10/1/2012 7:22 PM, Steven Schveighoffer wrote:
>> Does it make sense for Phobos to provide such a shortcut in an obscure
>> header somewhere? Like std.cstring? Or should we just say "roll your own
>> if you need it"?
>
> As a matter of principle, I really don't like gobs of Phobos functions
> that are literally one liners. Phobos should not become a mile wide but
> inch deep library of trivia. It should consist of non-trivial, useful,
> and relatively deep functions.

Well there are some possible reasons. Clearly useful functionality 
that's nontrivial deserves being abstracted in a function. On the other 
hand, even a short function is valuable if frequent enough and deserving 
of a name. We have e.g. s.strip even though it's equivalent to 
s.stripLeft.stripRight.

Andrei
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
Le 01/10/2012 22:33, Vladimir Panteleev a écrit :
> On Monday, 1 October 2012 at 12:12:52 UTC, deadalnix wrote:
>> Le 01/10/2012 13:29, Vladimir Panteleev a écrit :
>>> On Monday, 1 October 2012 at 10:56:36 UTC, deadalnix wrote:
>>>> How does to!string know that the string is 0 terminated ?
>>>
>>> By convention (it doesn't).
>>
>> It is unsafe as hell oO
>
> Forcing the programmer to put strlen calls everywhere in his code is not
> any safer.

I make the library safer. If the programmer manipulate unsafe construct 
(like c strings) it is up to the programmer to ensure safety, not the lib.
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
Le 02/10/2012 03:13, Walter Bright a écrit :
> On 9/30/2012 11:31 AM, deadalnix wrote:
>> If you know that a string is 0 terminated, you can easily create a slice
>> from it as follow :
>>
>> char* myZeroTerminatedString;
>> char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)];
>>
>> It is clean and avoid to modify the stdlib in an unsafe way.
>
>
> Of course, using strlen() is always going to be unsafe. But having %zs
> is equally unsafe for the same reason.
>
> deadalnix's example shows that adding a new format specifier %zs adds
> little value, but it gets much worse. Since %zs is inherently unsafe, it
> hides such unsafety in a commonly used library function, which will
> infect everything else that transitively calls writefln with unsafety.
>
> This makes %zs an unacceptable feature.

Exactly my point.
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tue, 02 Oct 2012 04:09:43 -0400, Walter Bright  
<newshound1@digitalmars.com> wrote:

> On 10/1/2012 7:22 PM, Steven Schveighoffer wrote:
>> Does it make sense for Phobos to provide such a shortcut in an obscure
>> header somewhere? Like std.cstring? Or should we just say "roll your own
>> if you need it"?
>
> As a matter of principle, I really don't like gobs of Phobos functions  
> that are literally one liners. Phobos should not become a mile wide but  
> inch deep library of trivia. It should consist of non-trivial, useful,  
> and relatively deep functions.

This, arguably, is one of the most important aspects of C to support.   
There are lots of C functions which provide C strings.  Yes, we don't want  
to promote using C strings, but to have one point of conversion so you  
*can* use safe strings is a good thing.  In other words, the sooner you  
convert your zero-terminated strings to char slices, the better off you  
are.  And if we label it system code, it can't be misused in @safe code.

Why support zero-terminated strings as literals if it wasn't important?   
You could argue that things like system calls which return zero-terminated  
strings are as safe to use as string literals which you know have zero  
terminated values.

The only other alternative is to wrap those C functions with D ones that  
convert to char[].  I don't find this any more appealing.

-Steve
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tuesday, 2 October 2012 at 02:22:33 UTC, Steven Schveighoffer 
wrote:
> @system char[] zstr(char *s) { return s[0..strlen(s)]; }
>
> […]
>
> Does it make sense for Phobos to provide such a shortcut in an 
> obscure header somewhere?  Like std.cstring?  Or should we just 
> say "roll your own if you need it"?

I didn't look it up, so I could be making quite a fool of myself 
right now, but doesn't to!string(char*) provide exactly that?

David
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tue, 02 Oct 2012 15:17:42 -0400, David Nadlinger <see@klickverbot.at>  
wrote:

> On Tuesday, 2 October 2012 at 02:22:33 UTC, Steven Schveighoffer wrote:
>> @system char[] zstr(char *s) { return s[0..strlen(s)]; }
>>
>> […]
>>
>> Does it make sense for Phobos to provide such a shortcut in an obscure  
>> header somewhere?  Like std.cstring?  Or should we just say "roll your  
>> own if you need it"?
>
> I didn't look it up, so I could be making quite a fool of myself right  
> now, but doesn't to!string(char*) provide exactly that?

string is immutable.  Must allocate.

You fool :)  just kidding, honest mistake.

-Steve
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tuesday, 2 October 2012 at 19:31:33 UTC, Steven Schveighoffer 
wrote:
> On Tue, 02 Oct 2012 15:17:42 -0400, David Nadlinger 
> <see@klickverbot.at> wrote:
>
>> On Tuesday, 2 October 2012 at 02:22:33 UTC, Steven 
>> Schveighoffer wrote:
>>> @system char[] zstr(char *s) { return s[0..strlen(s)]; }
>>>
>>> […]
>>>
>>> Does it make sense for Phobos to provide such a shortcut in 
>>> an obscure header somewhere?  Like std.cstring?  Or should we 
>>> just say "roll your own if you need it"?
>>
>> I didn't look it up, so I could be making quite a fool of 
>> myself right now, but doesn't to!string(char*) provide exactly 
>> that?
>
> string is immutable.  Must allocate.
>
> You fool :)

Well, make it to!char(char*) then! ;)

David
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tuesday, 2 October 2012 at 19:34:31 UTC, David Nadlinger wrote:
> Well, make it to!char(char*) then! ;)

Oh dear, this doesn't get better: Of course, I've meant to write 
»to!(char[])(char*)«.

David
1 2 3 4 5 6
Top | Discussion index | About this forum | D home