On 11/18/2014 9:01 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 16 November 2014 at 21:54:40 UTC, Walter Bright wrote:
>> Besides, C was designed for the PDP-11, which had no such instructions.
>
> BTW, this is not entirely correct. It had autoincrement on registers.

Those are not dedicated string instructions. Autoincrement was an addressing mode that could be used with any register and any instruction, including the stack and program counter (!).

Autoincrement/autodecrement gave rise to *p++ and *p-- in C.

> This is the example given on Wikipedia:
>
>   MOV #MSG,R1
> 1$: MOVB (R1)+,R0
>   BEQ DONE
>   .TTYOUT
>   BR 1$
>   .EXIT
>
> MSG: .ASCIZ /Hello, world!/
>
> The full example:
>
> http://en.wikipedia.org/wiki/MACRO-11

More than destroyed by every time you have to call strlen().


> So the print loop is 4 instructions (I assume .TTYOUT is a I/O instruction),
> with a length you would at least have 5 instructions and use an extra register,
> as you would have an additional compare.

.TTYOUT is a macro that expands to code that calls the operating system. The 11 doesn't have I/O instructions.


> (As for concat, that I almost never use. In systems programming you mostly
> append to buffers and flush when the buffer is full. Don't need length for that.

Uh, you need the length to determine when "the buffer is full".


> Even in javascript and python  I avoid regular concat due to the inefficency of
> concat versus a buffered join.)

Just try to manipulate paths, filenames, and extensions without using strlen() and strcat(). Your claim that C string code doesn't use strlen() is patently absurd.

Besides, you wouldn't be using javascript or python if efficiency mattered.

On 11/18/2014 12:53 PM, Paulo Pinto wrote:
> On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:
>> (C has added useless enhancements, like VLAs.)
>
> So useless that it became optional in C11.
>
> https://groups.google.com/forum/#!topic/comp.std.c/AoB6LFHcd88

Note the Rationale given:

---

- Putting arbitrarily large arrays on the stack causes trouble
in multithreaded programs in implementations where stack growth
is bounded.

- There's no way to recover from an out-of-memory condition when
allocating a VLA.

- Microsoft declines to support them.

- VLAs aren't used much.  There appear to be only three in
Google Code, and no VLA parameters. The Linux kernel had one,
but it was taken out because there was no way to handle an
out of space condition.  (If anyone can find an example of
a VLA parameter in publicly visible production code, please
let me know.)

- The semantics of VLA parameters is painful.  They're
automatically reduced to pointers, with the length information
lost.  "sizeof" returns the size of a pointer.

- Prototypes of functions with VLA parameters do not have
to exactly match the function definition. This is
incompatible with C++ style linkage and C++ function
overloading, preventing the extension of this feature
into C++.

                        John Nagle

On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d wrote:
> On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
> >>I'm sorry to say this, but these rationalizations as to why C cannot add a trivial enhancement that takes nothing away and solves most of the buffer overflow problems leaves me shaking my head.
> >
> >What's the trivial thing that will solve most buffer overflow problems?
> 
> http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625

That's not a trivial change at all -- it will break pretty much every C program there is out there. Just think of how much existing C code relies on this conflation between arrays and pointers, and implicit conversions between them.

Once you start going down that path, you might as well just start over with a brand new language. Which ultimately leads to D. :-P


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.

On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:
> I'm sorry to say this, but these rationalizations as to why C cannot add a trivial enhancement that takes nothing away and

They can add whatever they want.

I am arguing against the position that it was a design mistake to keep the semantic model simple and with few presumptions. On the contrary, it was the design goal. Another goal for a language like C is ease of implementation so that you can easily port it to new hardware.

The original C was a very simple language. Most decent programmers can create their own C-compiler (but not a good optimizer).

> (C has added useless enhancements, like VLAs.)

VLAs have been available in gcc for a long time. They are not useless, I've used them from time to time.

On Tuesday, 18 November 2014 at 21:07:22 UTC, Walter Bright wrote:
> Those are not dedicated string instructions. Autoincrement was an addressing mode that could be used with any register and any instruction, including the stack and program counter (!).

Yes, Motorola 68000 also had those. Very useful combined with sentinels! ;^) It was one of those things that made the 68K asm feel a bit like a high level language.

> Autoincrement/autodecrement gave rise to *p++ and *p-- in C.

Might have, but not from PDP-11. It came to C from B which predated PDP-11.

> More than destroyed by every time you have to call strlen().

Don't!

And factor in the performance loss coming from reading from punched tape… ;-)

(Actually sentinels between fields are also better for recovery if you have data corruption in files, although there are many other solutions, but this is a non-problem today.)

> .TTYOUT is a macro that expands to code that calls the operating system. The 11 doesn't have I/O instructions.

Ah, ok, so it was a system call.

> Uh, you need the length to determine when "the buffer is full".

For streaming: fixed size, modulo 2.

For allocating: worst case allocate, then release.

> Just try to manipulate paths, filenames, and extensions without using strlen() and strcat(). Your claim that C string code doesn't use strlen() is patently absurd.

No, I don't claim that I never used strlen(), but I never used strcat() IIRC, and never had the need to repeatedly call strlen() on long strings. Long strings would usually sit in a struct where there is space for a length. Slightly annoying, but not the big deal.

Filenames are easy, just allocate a large fixed size buffer, then fill in. open(). reuse buffer.

> Besides, you wouldn't be using javascript or python if efficiency mattered.

Actually, lately most of my efficiency related programming is done in javascript!  I spend a lot of time breaking up javascript code into async calls to get good responsiveness. But most of my efficiency related problems are in browser engine layout-code (not javascript) that I have to work around somehow.

Javascript in isolation is getting insanely fast in the last generations of browser JITs. It is almost a bit scary, because that means that we might be stuck with it forever…

On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
>>> On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
>>>> I'm sorry to say this, but these rationalizations as to why C cannot
>>>> add a trivial enhancement that takes nothing away and solves most of
>>>> the buffer overflow problems leaves me shaking my head.
>>>
>>> What's the trivial thing that will solve most buffer overflow
>>> problems?
>>
>> http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625
>
> That's not a trivial change at all -- it will break pretty much every C
> program there is out there. Just think of how much existing C code
> relies on this conflation between arrays and pointers, and implicit
> conversions between them.

No, I proposed a new syntax that would have different behavior:

  void foo(char a[..])

On Tue, Nov 18, 2014 at 02:14:20PM -0800, Walter Bright via Digitalmars-d wrote:
> On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d wrote:
> >>On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
> >>>On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
> >>>>I'm sorry to say this, but these rationalizations as to why C cannot add a trivial enhancement that takes nothing away and solves most of the buffer overflow problems leaves me shaking my head.
> >>>
> >>>What's the trivial thing that will solve most buffer overflow problems?
> >>
> >>http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625
> >
> >That's not a trivial change at all -- it will break pretty much every C program there is out there. Just think of how much existing C code relies on this conflation between arrays and pointers, and implicit conversions between them.
> 
> No, I proposed a new syntax that would have different behavior:
> 
>   void foo(char a[..])

Ah, I see. How would that be different from just declaring an array struct and using it pervasively? Existing C code would not benefit from such an addition without a lot of effort put into refactoring.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton

On 11/18/2014 2:35 PM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Nov 18, 2014 at 02:14:20PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:
>> No, I proposed a new syntax that would have different behavior:
>>
>>    void foo(char a[..])
>
> Ah, I see. How would that be different from just declaring an array
> struct and using it pervasively?

  foo("string");

won't work using a struct parameter.


> Existing C code would not benefit from
> such an addition without a lot of effort put into refactoring.

Except that the syntax is not viral and can be done as convenient. And, as mentioned in the article, people do make the effort to do other, much more complicated, schemes.

On 11/18/2014 1:23 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> I am arguing against the position that it was a design mistake to keep the
> semantic model simple and with few presumptions. On the contrary, it was the
> design goal. Another goal for a language like C is ease of implementation so
> that you can easily port it to new hardware.

The proposals I made do not change that in any way, and if K&R designed C without those mistakes, it would have not made C more complex in the slightest.


> VLAs have been available in gcc for a long time. They are not useless, I've used
> them from time to time.

I know you're simply being argumentative when you defend VLAs, a complex and useless feature, and denigrate simple ptr/length pairs as complicated.

On 11/18/2014 1:56 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Filenames are easy, just allocate a large fixed size buffer, then fill in.
> open(). reuse buffer.

    char s[] = "filename.ext";
    foo(s[0..8]);

But hey, it's simpler, faster, less code, less bug prone, easier to understand and uses less memory to:

1. strlen
2. allocate
3. memcpy
4. append a 0
   foo
5. free

instead, right?

I know you said "just allocate a large fixed size buffer", but I hope you realize that such practice is the root cause of most buffer overflow bugs, because the "640K is enough for anyone" just never works.

And your "just use a struct" argument also promptly falls apart with:

    foo("string")

Now, I know that you'll never concede destruction, after all, this is the internet, but give it up :-)