View mode: basic / threaded / horizontal-split · Log in · Help
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tue, 02 Oct 2012 15:35:47 -0400, David Nadlinger <see@klickverbot.at>  
wrote:

> 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*)«.

Right.  I agree, this should not allocate (I think someone said it does,  
but it's probably not necessary to).

But still, what looks better?

auto x = SomeSystemCallThatReturnsACString();

writefln("%s", to!(char[])(x));
writefln("%s", zstr(x));

I want something easy to type, and not too difficult to visually parse.

In fact, a better solution would be to define a C string type (other than  
char *), and just pretend those system calls return that.  Then support  
that C string type in writef.

-Steve
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On 10/2/12, Walter Bright <newshound1@digitalmars.com> wrote:
> 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)];
> 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.

How does it hide anything if you have to explicitly mark the format
specifier as %zs? It would be documented, just like it's documented
that passing pointers to garbage-collected memory to the C side is
inherently unsafe.

> deadalnix's example shows that adding a new format specifier %zs adds
> little value.

It adds convenience, which is an important trait in this day and age.
If that's not a concern, why is printf a symbol you can get your hands
on as soon as you import std.stdio? And if safety is a concern why is
printf used in Phobos at all? I count 427 lines of printf calls in
Phobos and 843 lines in Druntime (druntime might have a good excuse
since it shouldn't import Phobos functions). Many of these calls in
Phobos are not simple D string literal printf calls either.

Btw, some weeks ago when dstep was announced you were jumping for joy
and were instantly proposing language changes to add better support
for wrapping C. But asking for better library support is somehow
controversial. I don't understand the double-standard.
October 02, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tuesday, 2 October 2012 at 21:30:35 UTC, Andrej Mitrovic wrote:
> On 10/2/12, Walter Bright <newshound1@digitalmars.com> wrote:
>> 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)];
>> 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.
>
> How does it hide anything if you have to explicitly mark the 
> format
> specifier as %zs? It would be documented, just like it's 
> documented
> that passing pointers to garbage-collected memory to the C side 
> is
> inherently unsafe.

writefln cannot be @safe if it has to support an unsafe format 
specifier. It's "hidden" because it affects every call to 
writefln, even if it doesn't use the unsafe format specifier.
October 03, 2012
Re: Idea: Introduce zero-terminated string specifier
On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> writefln cannot be @safe if it has to support an unsafe format
> specifier. It's "hidden" because it affects every call to
> writefln, even if it doesn't use the unsafe format specifier.

Ah damn I completely forgot about @safe. I tend to avoid recent features..

OK then I think my arguments are moot. Nevertheless I can always
define a helper function for my own purposes I guess.

Sorry Walter for not taking @safe into account. :)
October 03, 2012
Re: Idea: Introduce zero-terminated string specifier
On Wed, Oct 03, 2012 at 03:07:14AM +0200, Andrej Mitrovic wrote:
> On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> > writefln cannot be @safe if it has to support an unsafe format
> > specifier. It's "hidden" because it affects every call to writefln,
> > even if it doesn't use the unsafe format specifier.
[...]

Hmm, this seems to impose unnecessary limitations on @safe. I guess the
current language doesn't allow for a "conditionally-safe" tag where
something can be implicitly marked @safe if it's provable at
compile-time that it's safe?


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
October 03, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tuesday, October 02, 2012 18:21:30 H. S. Teoh wrote:
> On Wed, Oct 03, 2012 at 03:07:14AM +0200, Andrej Mitrovic wrote:
> > On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> > > writefln cannot be @safe if it has to support an unsafe format
> > > specifier. It's "hidden" because it affects every call to writefln,
> > > even if it doesn't use the unsafe format specifier.
> 
> [...]
> 
> Hmm, this seems to impose unnecessary limitations on @safe. I guess the
> current language doesn't allow for a "conditionally-safe" tag where
> something can be implicitly marked @safe if it's provable at
> compile-time that it's safe?

The format string is a runtime argument, so nothing can be proven about it at 
compile time.

If you want any kind of @safe inferrence, you need to use a template. If 
writefln took the format string as a template argument and generated different 
code (which was @safe or not depending on what it did) based on what was in 
the format string, then inferrence could take place, but otherwise no.

- Jonathan M Davis
October 03, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tue, Oct 02, 2012 at 07:50:09PM -0700, Jonathan M Davis wrote:
> On Tuesday, October 02, 2012 18:21:30 H. S. Teoh wrote:
> > On Wed, Oct 03, 2012 at 03:07:14AM +0200, Andrej Mitrovic wrote:
> > > On 10/3/12, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> > > > writefln cannot be @safe if it has to support an unsafe format
> > > > specifier. It's "hidden" because it affects every call to
> > > > writefln, even if it doesn't use the unsafe format specifier.
> > 
> > [...]
> > 
> > Hmm, this seems to impose unnecessary limitations on @safe. I guess
> > the current language doesn't allow for a "conditionally-safe" tag
> > where something can be implicitly marked @safe if it's provable at
> > compile-time that it's safe?
> 
> The format string is a runtime argument, so nothing can be proven
> about it at compile time.
> 
> If you want any kind of @safe inferrence, you need to use a template.
> If writefln took the format string as a template argument and
> generated different code (which was @safe or not depending on what it
> did) based on what was in the format string, then inferrence could
> take place, but otherwise no.
[...]

Yes that's what I mean. If the format string is known at compile-time
and known to involve only @safe code, then this would work. Something
like this might work if CTFE is used to parse the format string
piecemeal (i.e., translate something like writefln("%d %s",x,y) into
write!int(x); write!string(" "); write!string(y)). The safe instances of
write!T(...) will be marked @safe. But it does seem like a lot of work
just so we can use @safe, though. I suppose we could just use @trusted
and call it a day.


T

-- 
Claiming that your operating system is the best in the world because
more people use it is like saying McDonalds makes the best food in the
world. -- Carl B. Constantine
October 03, 2012
Re: Idea: Introduce zero-terminated string specifier
On Wednesday, 3 October 2012 at 05:04:01 UTC, H. S. Teoh wrote:
> Yes that's what I mean. If the format string is known at 
> compile-time
> and known to involve only @safe code, then this would work. 
> Something
> like this might work if CTFE is used to parse the format string
> piecemeal (i.e., translate something like writefln("%d %s",x,y) 
> into
> write!int(x); write!string(" "); write!string(y)). The safe 
> instances of
> write!T(...) will be marked @safe.

It doesn't matter if the argument is known at compile-time or 
not, because there's no way to know that without receiving the 
format string as a template parameter, in which case it must 
*always* be known at compile-time (runtime format string would 
not be supported), and then the syntax is no longer writefln("%d 
%s", x, y). Obviously, such a change is not acceptable.

> I suppose we could just use @trusted
> and call it a day.

No, that would be abusing @trusted. The function would no longer 
be safe, *because it contains possibly unsafe code*. @trusted is 
for safe functions that the compiler cannot prove safe.
October 03, 2012
Re: Idea: Introduce zero-terminated string specifier
On Wednesday, October 03, 2012 07:35:23 Jakob Ovrum wrote:
> > I suppose we could just use @trusted
> > and call it a day.
> 
> No, that would be abusing @trusted. The function would no longer
> be safe, *because it contains possibly unsafe code*. @trusted is
> for safe functions that the compiler cannot prove safe.

Yeah. You basically _never_ just mark @trusted and call it a day. You only 
mark something @trusted if you've verified that _everything_ that that function 
does which is @system is done in a way that's ultimately @safe. In particular, 
marking much of anything which is templated as @trusted is almost always just 
plain wrong.

- Jonathan M Davis
October 03, 2012
Re: Idea: Introduce zero-terminated string specifier
On Tue, 02 Oct 2012 21:44:11 +0100, Steven Schveighoffer  
<schveiguy@yahoo.com> wrote:
> In fact, a better solution would be to define a C string type (other  
> than char *), and just pretend those system calls return that.  Then  
> support that C string type in writef.
>
> -Steve

:D
http://comments.gmane.org/gmane.comp.lang.d.general/97793

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
1 2 3 4 5 6
Top | Discussion index | About this forum | D home