On 15.05.2012 20:19, Gor Gyolchanyan wrote:
>
>
> On Tue, May 15, 2012 at 7:51 PM, Christophe
> <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.

Moreover compiler can do some extra string pooling iff zero termination goes away. Like:
"Hello World!" & "Hello" sharing the same piece of ROM.


-- 
Dmitry Olshansky

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

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>> 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 !

On 15-05-2012 18:19, Gor Gyolchanyan wrote:
>
>
> On Tue, May 15, 2012 at 7:51 PM, Christophe
> <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!

Nope. write* perform GC allocation.

> 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.

You're assuming everyone uses Phobos. This is not the case.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Tuesday, 15 May 2012 at 16:22:22 UTC, Dmitry Olshansky wrote:
> Moreover compiler can do some extra string pooling iff zero termination goes away. Like:
> "Hello World!" & "Hello" sharing the same piece of ROM.

Has anyone actually done some research on how much space this could actually save in practice?

David

>> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen <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.
2. writef and friends could get cousins like nogcwritef and nogcwritefln.
(see comments beloaw)
3. GC can be turned off and gc-allocated memory can be GC.freeed.
4. printf could get wrapped to take d-strings by malloc-ing new buffers for
the c-strings if necessary.

>> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen <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.

-- 
Bye,
Gor Gyolchanyan.

On Tue, May 15, 2012 at 9:23 PM, David Nadlinger <see@klickverbot.at> wrote:

> On Tuesday, 15 May 2012 at 16:22:22 UTC, Dmitry Olshansky wrote:
>
>> Moreover compiler can do some extra string pooling iff zero termination
>> goes away. Like:
>> "Hello World!" & "Hello" sharing the same piece of ROM.
>>
>
> Has anyone actually done some research on how much space this could actually save in practice?
>
> David
>

It can't be accurately measured, because the number of string literals available at a single compiler pass is vastly varying.

-- 
Bye,
Gor Gyolchanyan.

On Tuesday, 15 May 2012 at 17:30:53 UTC, Gor Gyolchanyan wrote:
> It can't be accurately measured, because the number of string literals
> available at a single compiler pass is vastly varying.

Of course the actual amount varies from application to application, but it should be possible to obtain some ballpark figures for usual and for string-heavy applications…

David

On 05/15/2012 10:39 AM, deadalnix wrote:
> Le 14/05/2012 19:38, Alex Rønne Petersen a écrit :
>> On 14-05-2012 15:21, Gor Gyolchanyan wrote:
>>> I thing the zero-terminated literal shtick is pointless. Literals are
>>> rarely passed to C functions, so we gotta use the std.utf.toUTFz anyway.
>>>
>>> On Mon, May 14, 2012 at 5:03 PM, Christophe
>>> <travert@phare.normalesup.org <mailto:travert@phare.normalesup.org>>
>>> wrote:
>>>
>>> deadalnix , dans le message (digitalmars.D:167258), a écrit :
>>> > A good solution would be to set the pointer to 0 when the length
>>> is set
>>> > to 0.
>>>
>>> String literal are zero-terminated. "" cannot point to 0x0,
>>> unless we drop this rule. Maybe we should...
>>>
>>>
>>>
>>>
>>> --
>>> Bye,
>>> Gor Gyolchanyan.
>>
>> This is very false. I invite you to read almost any module in druntime.
>> You'll find that it makes heavy use of printf debugging.
>>
>> That being said, dropping the null-termination rule when passing strings
>> to non-const(char)* parameters/variables/etc would be sane enough (I
>> think).
>>
>
> This looks to me like a bad practice. C string and D string are
> different beasts, and we have toStringz .
>

It is not. Claiming valid use cases are bad practice does not help the discussion. It is disrespectful and patronising.

> It is kind of dumb to create a WAT is the language because druntime dev
> did mistakes.

The conclusion is based on a wrong premise therefore it is meaningless.

> It have to be fixed.

It can be fixed better by making (null !is []) hold instead of making ("" is null) hold.

On 05/15/2012 06:19 PM, Gor Gyolchanyan wrote:
>
>
> On Tue, May 15, 2012 at 7:51 PM, Christophe
> <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!

First of all, 'is' shouldn't be used to compare built-in arrays!

> There's writef and it's superior to printf in any way!

No it is not! printf and scanf are so much faster than writef/readf that it is relevant! The poor performance of writef/readf makes it embarrassing for a university to use D as a teaching language!

> 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.

There are none in the current scheme.