View mode: basic / threaded / horizontal-split · Log in · Help
May 15, 2012
Re: The more interesting question
On 15-05-2012 19:29, Gor Gyolchanyan wrote:
>  >> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen <alex@lycus.org
> <mailto:alex@lycus.org>> wrote:
>  >> Nope. write* perform GC allocation.
>
> 1. Give me the top 3 use cases, where GC allocation is intolerable when
> writing to an output stream.

Who the hell am I or you to dictate use cases? But a few off the top of 
my head:

1) Building without a GC *at all* (and yes, it is possible).
2) When writing high performance tools for doing UNIX-style program 
output piping.

> 2. writef and friends could get cousins like nogcwritef and
> nogcwritefln. (see comments beloaw)

Patches welcome.

> 3. GC can be turned off and gc-allocated memory can be GC.freeed.

Yes, if you alter the implementation. You can't free it from the call 
site. Again, patches welcome.

> 4. printf could get wrapped to take d-strings by malloc-ing new buffers
> for the c-strings if necessary.

And just about every C function taking strings, ever. This is a bad 
strategy, and makes D's C interoperability worse.

>
>  >> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen <alex@lycus.org
> <mailto:alex@lycus.org>> wrote:
>  >> You're assuming everyone uses Phobos. This is not the case.
>
> I'm assuming everyone is sane, because Phobos is called "the standard
> library" for a damned good reason. For those who don't - they're welcome
> to use whatever they want and convert d-strings to c-strings any way
> they choose if necessary.

Yes, let's cripple a systems language for the comfort of the non-systems 
programmers. Excellent idea.

>
> --
> Bye,
> Gor Gyolchanyan.

PS: Removing null-terminated string literals is not going to fix the 
array slice corner cases by itself. I think this discussion is fairly 
pointless. If you want to fix slices, go all the way with it, not just 
half the way.

Besides, this is probably not going to change anyway. We're focusing on 
stabilizing the language, not changing it.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 15, 2012
Re: The more interesting question
On 05/15/2012 06:45 PM, deadalnix wrote:
> Le 15/05/2012 17:51, Christophe a écrit :
>> deadalnix , dans le message (digitalmars.D:167404), a écrit :
>>> This looks to me like a bad practice. C string and D string are
>>> different beasts, and we have toStringz .
>>
>> C string and D string are different, but it's not a bad idea to have
>> string *literals* that works for both C and D strings, otherwise using
>> printf will lead to a bug each time the programmer forget the trailing
>> \0.
>>
>>> It is kind of dumb to create a WAT is the language because druntime dev
>>> did mistakes. It have to be fixed.
>>
>> You can't rely on an empty string to be null since you must be able to
>> reserve place at the end of the array, and or the string could be the
>> result of poping a full string.
>
> This is why I stated put null when the string length is SET to 0, not
> when it is 0.
>
> So it is nulled when I create an empty slice, or do arr.length = 0

Might as well start Microsoft Flight Simulator when the length is set to 
9797.

If you want to clear the contents of the array, use arr=null or arr=[].
May 15, 2012
Re: The more interesting question
On Tue, May 15, 2012 at 11:46 AM, deadalnix <deadalnix@gmail.com> wrote:

> Le 15/05/2012 18:19, Gor Gyolchanyan a écrit :
>
>>
>>
>> On Tue, May 15, 2012 at 7:51 PM, Christophe
>> <travert@phare.normalesup.org <mailto:travert@phare.**normalesup.org<travert@phare.normalesup.org>>>
>> wrote:
>>
>>    using printf will lead to a bug each time the programmer forget the
>>    trailing
>>    \0.
>>
>>
>> First of all, printf shouldn't be used! There's writef and it's superior
>> to printf in any way!
>> Second of all, if the zero-termination of literals are to be removed,
>> the literals will no longer be accepted as a pointer to a character.
>> The appropriate type mismatch error will force the user to use toUTF8z
>> to get ht e zero-terminated utf-8 version of the original string.
>> In case it's a literal, one could use the compile-time version of
>> toUTF8z to avoid run-time overhead.
>> This all doesn't sound like a bad idea to me. I don't see any security
>> or performance flaws in this scheme.
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> May god ear you !
>

Unfortunately, using writef/writefln would make DRuntime depend on Phobos,
which is unacceptable.
May 15, 2012
Re: The more interesting question
Le 15/05/2012 21:57, Andrew Wiley a écrit :
> On Tue, May 15, 2012 at 11:46 AM, deadalnix <deadalnix@gmail.com
> <mailto:deadalnix@gmail.com>> wrote:
>
>     Le 15/05/2012 18:19, Gor Gyolchanyan a écrit :
>
>
>
>         On Tue, May 15, 2012 at 7:51 PM, Christophe
>         <travert@phare.normalesup.org
>         <mailto:travert@phare.normalesup.org>
>         <mailto:travert@phare.__normalesup.org
>         <mailto:travert@phare.normalesup.org>>> wrote:
>
>             using printf will lead to a bug each time the programmer
>         forget the
>             trailing
>             \0.
>
>
>         First of all, printf shouldn't be used! There's writef and it's
>         superior
>         to printf in any way!
>         Second of all, if the zero-termination of literals are to be
>         removed,
>         the literals will no longer be accepted as a pointer to a character.
>         The appropriate type mismatch error will force the user to use
>         toUTF8z
>         to get ht e zero-terminated utf-8 version of the original string.
>         In case it's a literal, one could use the compile-time version of
>         toUTF8z to avoid run-time overhead.
>         This all doesn't sound like a bad idea to me. I don't see any
>         security
>         or performance flaws in this scheme.
>         --
>         Bye,
>         Gor Gyolchanyan.
>
>
>     May god ear you !
>
>
> Unfortunately, using writef/writefln would make DRuntime depend on
> Phobos, which is unacceptable.
>

druntime isn't supposed to printf stuff.
May 15, 2012
Re: The more interesting question
Le 15/05/2012 20:34, Alex Rønne Petersen a écrit :
> Besides, this is probably not going to change anyway. We're focusing on
> stabilizing the language, not changing it.
>

This always have been a design mistake to auto cast array in pointers. 
This is silent fallback to usafe world, and what we want to avoid.

This has no benefit because using .ptr isn't really complex and make the 
transition obvious.

This has been raised many time in the past as being an issue, and it fit 
nicely here.

Having \0 terminated string in D were it has no usage is quite dumb.
May 15, 2012
Re: The more interesting question
Le 15/05/2012 17:51, Christophe a écrit :
> deadalnix , dans le message (digitalmars.D:167404), a écrit :
>> This looks to me like a bad practice. C string and D string are
>> different beasts, and we have toStringz .
>
> C string and D string are different, but it's not a bad idea to have
> string *literals* that works for both C and D strings, otherwise using
> printf will lead to a bug each time the programmer forget the trailing
> \0.
>

Due to slicing, it is already unsafe to pass a D string to C code. The 
main problem is array casting silently to pointers, making the error 
easy to do.

Fixing the problem for literal isn't going to solve it at all.

The real solution is toStringz
May 16, 2012
Re: The more interesting question
On 05/16/2012 12:29 AM, deadalnix wrote:
> Le 15/05/2012 20:34, Alex Rønne Petersen a écrit :
>> Besides, this is probably not going to change anyway. We're focusing on
>> stabilizing the language, not changing it.
>>
>
> This always have been a design mistake to auto cast array in pointers.
> This is silent fallback to usafe world, and what we want to avoid.
>

Getting a pointer to the beginning of a zero-terminated string literal 
is perfectly safe.

> This has no benefit because using .ptr isn't really complex and make the
> transition obvious.
>
> This has been raised many time in the past as being an issue, and it fit
> nicely here.
>

This is a compile time error:

int[] arr;
int* p=arr;

What exactly are you asking for?

> Having \0 terminated string in D were it has no usage is quite dumb.

What you don't seem to get is that it actually has usage.
May 16, 2012
Re: arrays: if(null == [ ])
On Tue, 15 May 2012 04:42:10 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 14/05/2012 21:53, Steven Schveighoffer a écrit :
>> On Mon, 14 May 2012 15:30:25 -0400, deadalnix <deadalnix@gmail.com>  
>> wrote:
>>
>>> Le 14/05/2012 16:37, Steven Schveighoffer a écrit :
>>>> Note that [] is a request to the runtime to build an empty array. The
>>>> runtime detects this, and rather than consuming a heap allocation to
>>>> build nothing, it simply returns a null-pointed array. This is 100%  
>>>> the
>>>> right decision, and I don't think anyone would ever convince me (or
>>>> Andrei or Walter) otherwise.
>>>>
>>>
>>> Obviously this is the right thing to do !
>>>
>>> The question is why an array of length 0 isn't nulled ? It lead to
>>> confusing semantic here, and can keep alive memory that can't be
>>> accessed.
>>
>> int[] arr;
>> arr.reserve(10000);
>> assert(arr.length == 0);
>>
>> -Steve
>
> The length isn't set to 0 here. You obviously don't want that to be  
> nulled.

The assert disagrees with you :)

-Steve
May 16, 2012
Re: arrays: if(null == [ ])
On Mon, 14 May 2012 18:07:24 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 05/14/2012 01:51 PM, deadalnix wrote:
>> Le 14/05/2012 12:49, Gor Gyolchanyan a écrit :
>>> So, null arrays and empty arrays are always the same, except for an
>>> empty string, which is a valid non-nill array of characters with length
>>> 0, right?
>>>
>>
>> If it is the current behavior, it deserve a WAT !
>
> I agree, but it is explained easily. Built-in string literals are always  
> zero-terminated, therefore an empty string literal must point into  
> accessible memory. I'd like to have [] !is null as well, so that null  
> can reliably be used as a sentinel value.

This would mean either a) allocating memory for a 0 length array, or b)  
pointing it at non-null but non-heap memory.

a) is certainly out of the question.

b) is possible, but I still think we should discourage using null as a  
sentinel, it leads to confusing code.

Regardless, we should fix if(!arr) to mean if(!arr.length).

-Steve
May 16, 2012
Re: The more interesting question
On Tue, 15 May 2012 18:31:26 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 15/05/2012 17:51, Christophe a écrit :
>> deadalnix , dans le message (digitalmars.D:167404), a écrit :
>>> This looks to me like a bad practice. C string and D string are
>>> different beasts, and we have toStringz .
>>
>> C string and D string are different, but it's not a bad idea to have
>> string *literals* that works for both C and D strings, otherwise using
>> printf will lead to a bug each time the programmer forget the trailing
>> \0.
>>
>
> Due to slicing, it is already unsafe to pass a D string to C code. The  
> main problem is array casting silently to pointers, making the error  
> easy to do.

How so?  strings are immutable, and literals are *truly* immutable.

> Fixing the problem for literal isn't going to solve it at all.
>
> The real solution is toStringz

toStringz can allocate a new block in order to ensure 0 gets added.  This  
is ludicrous!

You are trying to tell me that any time I want to call a C function with a  
string literal, I have to first heap-allocate it, even though I *know*  
it's safe.

I don't see a "problem" anywhere.  The current system is perfect for what  
it needs to do.

-Steve
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home