Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140261 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2019-01-25 07:23 -0800 |
| Last post | 2019-01-25 14:28 -0800 |
| Articles | 20 on this page of 71 — 20 participants |
Back to article view | Back to comp.lang.c
Distributing C as headers. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:23 -0800
Re: Distributing C as headers. Thiago Adams <thiago.adams@gmail.com> - 2019-01-25 07:31 -0800
Re: Distributing C as headers. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:33 -0800
Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:42 +0000
Re: Distributing C as headers. gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-25 17:40 +0000
Re: Distributing C as headers. Thiago Adams <thiago.adams@gmail.com> - 2019-01-25 09:59 -0800
Re: Distributing C as headers. Thiago Adams <thiago.adams@gmail.com> - 2019-01-25 10:01 -0800
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-25 22:17 +0100
Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-25 21:33 +0000
Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-25 18:07 +0000
Re: Distributing C as headers. gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-25 18:46 +0000
Re: Distributing C as headers. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-01-25 19:43 -0700
Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-26 08:13 +0000
Re: Distributing C as headers. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-01-26 13:39 -0700
Re: Distributing C as headers. Mateusz Viste <mateusz@wont.tell> - 2019-01-26 21:00 +0000
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:29 +0100
Re: Distributing C as headers. nobody@example.org (Scott) - 2019-01-27 04:56 +0000
Re: Distributing C as headers. Dan Purgert <dan@djph.net> - 2019-01-27 11:36 +0000
Re: Distributing C as headers. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 12:26 -0800
Re: Distributing C as headers. "Jason C. McDonald" <indeliblebluepen@gmail.com> - 2019-02-28 19:52 +0000
Re: Distributing C as headers. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-28 15:04 -0500
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-28 21:40 +0100
Re: Distributing C as headers. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-28 13:57 -0800
Re: Distributing C as headers. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-01-27 13:33 +0000
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-27 15:06 +0100
Re: Distributing C as headers. luser droog <luser.droog@gmail.com> - 2019-01-26 13:01 -0800
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:30 +0100
Re: Distributing C as headers. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-02 09:27 +0000
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:23 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-26 13:39 -0800
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 22:47 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-26 14:33 -0800
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-26 23:37 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-26 15:09 -0800
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-27 15:11 +0100
Re: Distributing C as headers. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-27 16:12 -0500
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 00:51 +0100
Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 00:06 +0000
Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 00:18 +0000
Re: Distributing C as headers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-28 01:12 +0000
Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 01:35 +0000
Re: Distributing C as headers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-28 02:19 +0000
Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 10:40 +0000
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:22 +0100
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:21 +0100
Re: Distributing C as headers. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-28 04:03 -0800
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:23 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-28 11:16 -0800
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 21:08 +0100
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 01:19 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-27 16:59 -0800
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-27 16:33 -0800
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 01:35 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-27 17:20 -0800
Re: Distributing C as headers. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-27 22:50 -0500
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 06:52 +0100
Re: Distributing C as headers. Bart <bc@freeuk.com> - 2019-01-28 10:55 +0000
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:26 +0100
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:27 +0100
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:26 +0100
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 14:03 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-28 11:12 -0800
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-28 12:25 +0100
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 13:33 +0100
Re: Distributing C as headers. Keith Thompson <kst-u@mib.org> - 2019-01-28 11:20 -0800
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 21:11 +0100
Re: Distributing C as headers. scott@slp53.sl.home (Scott Lurndal) - 2019-01-28 21:12 +0000
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-28 23:06 +0100
Re: Distributing C as headers. David Brown <david.brown@hesbynett.no> - 2019-01-27 15:02 +0100
Re: Distributing C as headers. "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:51 +0100
Re: Distributing C as headers. fir <profesor.fir@gmail.com> - 2019-01-25 14:28 -0800
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-28 01:35 +0000 |
| Message-ID | <10t3E.125278$9A2.93679@fx09.am4> |
| In reply to | #140341 |
On 28/01/2019 01:12, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 28/01/2019 00:06, Bart wrote:
>>> On 27/01/2019 23:51, Pascal J. Bourguignon wrote:
>>
>>>> In C, you need a lot more information to be able to use the header.
>>>> In Pascal, you have all the information you need:
>>>>
>>>> var
>>>> dst:string;
>>>> begin
>>>> string_copy(dst,'Hello World');
>>>> end;
>>>>
>>>> will work without crashing.
>>>
>>> What would string_copy(dst, dst) do? What is the capacity of dst?
>>> (Last time I used Pascal, strings had to have a fixed length.)
>>
>> I couldn't compile your Pascal code. Do you have a real, complete
>> example that will run? I have Free Pascal Compiler.
>
> This is a runable example, though I have no idea if it illustrates
> whatever point was being made:
>
> program copystring (output);
> procedure string_copy(var dst : string; src : string);
> begin
> dst := src
> end;
> var dst : string;
> begin
> string_copy(dst, 'Hello World');
> write(dst)
> end.
Thanks. I think the point was that you couldn't make a Pascal program
crash, as the interfaces are more robust. However if I modify your
example to:
program copystring (output);
procedure string_copy(var dst : string; src : string);
begin
string_copy(dst,src)
end;
var dst : string;
begin
string_copy(dst, 'Hello World');
write(dst)
end.
then run via FPC it gives me:
Runtime error 202 at $0040142E
$0040142E
$00401441
$00401441
$00401441
$00401441
$00401441
$00401441
$00401441
$00401441
$00401441
(at a wild guess, it's run out of stack). I would say that it has crashed.
(Although apparently Pascal meant to write Lisp not Pascal, so it might
not count.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-01-28 02:19 +0000 |
| Message-ID | <8736pdv80w.fsf@bsb.me.uk> |
| In reply to | #140343 |
Bart <bc@freeuk.com> writes: > On 28/01/2019 01:12, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 28/01/2019 00:06, Bart wrote: >>>> On 27/01/2019 23:51, Pascal J. Bourguignon wrote: >>> >>>>> In C, you need a lot more information to be able to use the header. >>>>> In Pascal, you have all the information you need: >>>>> >>>>> var >>>>> dst:string; >>>>> begin >>>>> string_copy(dst,'Hello World'); >>>>> end; >>>>> >>>>> will work without crashing. >>>> >>>> What would string_copy(dst, dst) do? What is the capacity of dst? >>>> (Last time I used Pascal, strings had to have a fixed length.) >>> >>> I couldn't compile your Pascal code. Do you have a real, complete >>> example that will run? I have Free Pascal Compiler. >> >> This is a runable example, though I have no idea if it illustrates >> whatever point was being made: >> >> program copystring (output); >> procedure string_copy(var dst : string; src : string); >> begin >> dst := src >> end; >> var dst : string; >> begin >> string_copy(dst, 'Hello World'); >> write(dst) >> end. > > Thanks. I think the point was that you couldn't make a Pascal program crash, as the interfaces are more robust. However if I modify your example to: > > program copystring (output); > procedure string_copy(var dst : string; src : string); > begin > string_copy(dst,src) > end; > var dst : string; > begin > string_copy(dst, 'Hello World'); > write(dst) > end. > > then run via FPC it gives me: > > Runtime error 202 at $0040142E > $0040142E > $00401441 > $00401441 > $00401441 > $00401441 > $00401441 > $00401441 > $00401441 > $00401441 > $00401441 > > (at a wild guess, it's run out of stack). I would say that it has > crashed. I went and looked. James was talking about pointers so a more direct example might be this: program copystring (output); procedure string_copy(var dst : string; src : string); begin dst := src end; var dp : ^string; begin string_copy(dp^, 'Hello World'); write(dp^) end. > (Although apparently Pascal meant to write Lisp not Pascal, so it > might not count.) And I'm not sure that what he says counts. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-28 10:40 +0000 |
| Message-ID | <c_A3E.214950$ns2.7633@fx26.am4> |
| In reply to | #140344 |
On 28/01/2019 02:19, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> Thanks. I think the point was that you couldn't make a Pascal program crash, as the interfaces are more robust. However if I modify your example to: >> procedure string_copy(var dst : string; src : string); >> begin >> string_copy(dst,src) >> end; >> then run via FPC it gives me: >> >> Runtime error 202 at $0040142E > I went and looked. James was talking about pointers so a more direct > example might be this: > > program copystring (output); > procedure string_copy(var dst : string; src : string); > begin > dst := src > end; > var dp : ^string; > begin > string_copy(dp^, 'Hello World'); > write(dp^) > end. Yes, that crashes too (also with Runtime error, so it might be detecting and trapping such things, making it a softer crash). Also in this case the compiler warns about the uninitialised dp.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-28 12:22 +0100 |
| Message-ID | <m2tvhtc9i8.fsf@despina.home> |
| In reply to | #140347 |
Bart <bc@freeuk.com> writes: > On 28/01/2019 02:19, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> Thanks. I think the point was that you couldn't make a Pascal program crash, as the interfaces are more robust. However if I modify your example to: > >>> procedure string_copy(var dst : string; src : string); >>> begin >>> string_copy(dst,src) >>> end; > >>> then run via FPC it gives me: >>> >>> Runtime error 202 at $0040142E > >> I went and looked. James was talking about pointers so a more direct >> example might be this: >> >> program copystring (output); >> procedure string_copy(var dst : string; src : string); >> begin >> dst := src >> end; >> var dp : ^string; >> begin >> string_copy(dp^, 'Hello World'); >> write(dp^) >> end. > > Yes, that crashes too (also with Runtime error, so it might be > detecting and trapping such things, making it a softer crash). > > Also in this case the compiler warns about the uninitialised dp. Of course, you can write fortran code in any programming language… -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-28 12:21 +0100 |
| Message-ID | <m2y375c9it.fsf@despina.home> |
| In reply to | #140344 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Bart <bc@freeuk.com> writes: > >> On 28/01/2019 01:12, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> On 28/01/2019 00:06, Bart wrote: >>>>> On 27/01/2019 23:51, Pascal J. Bourguignon wrote: >>>> >>>>>> In C, you need a lot more information to be able to use the header. >>>>>> In Pascal, you have all the information you need: >>>>>> >>>>>> var >>>>>> dst:string; >>>>>> begin >>>>>> string_copy(dst,'Hello World'); >>>>>> end; >>>>>> >>>>>> will work without crashing. >>>>> >>>>> What would string_copy(dst, dst) do? What is the capacity of dst? >>>>> (Last time I used Pascal, strings had to have a fixed length.) >>>> >>>> I couldn't compile your Pascal code. Do you have a real, complete >>>> example that will run? I have Free Pascal Compiler. >>> >>> This is a runable example, though I have no idea if it illustrates >>> whatever point was being made: >>> >>> program copystring (output); >>> procedure string_copy(var dst : string; src : string); >>> begin >>> dst := src >>> end; >>> var dst : string; >>> begin >>> string_copy(dst, 'Hello World'); >>> write(dst) >>> end. >> >> Thanks. I think the point was that you couldn't make a Pascal program crash, as the interfaces are more robust. However if I modify your example to: >> >> program copystring (output); >> procedure string_copy(var dst : string; src : string); >> begin >> string_copy(dst,src) >> end; >> var dst : string; >> begin >> string_copy(dst, 'Hello World'); >> write(dst) >> end. >> >> then run via FPC it gives me: >> >> Runtime error 202 at $0040142E >> $0040142E >> $00401441 >> $00401441 >> $00401441 >> $00401441 >> $00401441 >> $00401441 >> $00401441 >> $00401441 >> $00401441 >> >> (at a wild guess, it's run out of stack). I would say that it has >> crashed. > > I went and looked. James was talking about pointers so a more direct > example might be this: > > program copystring (output); > procedure string_copy(var dst : string; src : string); > begin > dst := src > end; > var dp : ^string; > begin > string_copy(dp^, 'Hello World'); > write(dp^) > end. Part of the point that you could avoid using pointer in non-C programming languages. There are constructs such as passing arguments by reference, or using opaque objects (such as string) instead of bare pointers to characters with some missing attribute such as allocated size or length that must be passed on the side, which is propice to errors, and ultimately crashes. >> (Although apparently Pascal meant to write Lisp not Pascal, so it >> might not count.) > > And I'm not sure that what he says counts. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-01-28 04:03 -0800 |
| Message-ID | <3a437ac8-7cdc-4bfc-8871-17e706621b85@googlegroups.com> |
| In reply to | #140349 |
On Monday, 28 January 2019 11:21:56 UTC, Pascal J. Bourguignon wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > > > Bart <bc@freeuk.com> writes: > > > >> On 28/01/2019 01:12, Ben Bacarisse wrote: > >>> Bart <bc@freeuk.com> writes: > >>> > >>>> On 28/01/2019 00:06, Bart wrote: > >>>>> On 27/01/2019 23:51, Pascal J. Bourguignon wrote: > >>>> > >>>>>> In C, you need a lot more information to be able to use the header. > >>>>>> In Pascal, you have all the information you need: > >>>>>> > >>>>>> var > >>>>>> dst:string; > >>>>>> begin > >>>>>> string_copy(dst,'Hello World'); > >>>>>> end; > >>>>>> > >>>>>> will work without crashing. > >>>>> > >>>>> What would string_copy(dst, dst) do? What is the capacity of dst? > >>>>> (Last time I used Pascal, strings had to have a fixed length.) > >>>> > >>>> I couldn't compile your Pascal code. Do you have a real, complete > >>>> example that will run? I have Free Pascal Compiler. > >>> > >>> This is a runable example, though I have no idea if it illustrates > >>> whatever point was being made: > >>> > >>> program copystring (output); > >>> procedure string_copy(var dst : string; src : string); > >>> begin > >>> dst := src > >>> end; > >>> var dst : string; > >>> begin > >>> string_copy(dst, 'Hello World'); > >>> write(dst) > >>> end. > >> > >> Thanks. I think the point was that you couldn't make a Pascal program crash, as the interfaces are more robust. However if I modify your example to: > >> > >> program copystring (output); > >> procedure string_copy(var dst : string; src : string); > >> begin > >> string_copy(dst,src) > >> end; > >> var dst : string; > >> begin > >> string_copy(dst, 'Hello World'); > >> write(dst) > >> end. > >> > >> then run via FPC it gives me: > >> > >> Runtime error 202 at $0040142E > >> $0040142E > >> $00401441 > >> $00401441 > >> $00401441 > >> $00401441 > >> $00401441 > >> $00401441 > >> $00401441 > >> $00401441 > >> $00401441 > >> > >> (at a wild guess, it's run out of stack). I would say that it has > >> crashed. > > > > I went and looked. James was talking about pointers so a more direct > > example might be this: > > > > program copystring (output); > > procedure string_copy(var dst : string; src : string); > > begin > > dst := src > > end; > > var dp : ^string; > > begin > > string_copy(dp^, 'Hello World'); > > write(dp^) > > end. > > Part of the point that you could avoid using pointer in non-C > programming languages. There are constructs such as passing arguments > by reference, or using opaque objects (such as string) instead of bare > pointers to characters with some missing attribute such as allocated > size or length that must be passed on the side, which is propice to > errors, and ultimately crashes. > C allows you to create a wild pointer or one to a buffer which is too small, and then dereference it. Often the compiler will be unable to detect the situation and issue a warning. It's a huge problem, and probably the main reason C has been displaced on the desktop by various C enhancements.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-28 13:23 +0100 |
| Message-ID | <q2ms8d$cd5$1@dont-email.me> |
| In reply to | #140349 |
On 28/01/2019 12:21, Pascal J. Bourguignon wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Bart <bc@freeuk.com> writes: >> >>> On 28/01/2019 01:12, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 28/01/2019 00:06, Bart wrote: >>>>>> On 27/01/2019 23:51, Pascal J. Bourguignon wrote: >>>>> >>>>>>> In C, you need a lot more information to be able to use the header. >>>>>>> In Pascal, you have all the information you need: >>>>>>> >>>>>>> var >>>>>>> dst:string; >>>>>>> begin >>>>>>> string_copy(dst,'Hello World'); >>>>>>> end; >>>>>>> >>>>>>> will work without crashing. >>>>>> >>>>>> What would string_copy(dst, dst) do? What is the capacity of dst? >>>>>> (Last time I used Pascal, strings had to have a fixed length.) >>>>> >>>>> I couldn't compile your Pascal code. Do you have a real, complete >>>>> example that will run? I have Free Pascal Compiler. >>>> >>>> This is a runable example, though I have no idea if it illustrates >>>> whatever point was being made: >>>> >>>> program copystring (output); >>>> procedure string_copy(var dst : string; src : string); >>>> begin >>>> dst := src >>>> end; >>>> var dst : string; >>>> begin >>>> string_copy(dst, 'Hello World'); >>>> write(dst) >>>> end. >>> >>> Thanks. I think the point was that you couldn't make a Pascal program crash, as the interfaces are more robust. However if I modify your example to: >>> >>> program copystring (output); >>> procedure string_copy(var dst : string; src : string); >>> begin >>> string_copy(dst,src) >>> end; >>> var dst : string; >>> begin >>> string_copy(dst, 'Hello World'); >>> write(dst) >>> end. >>> >>> then run via FPC it gives me: >>> >>> Runtime error 202 at $0040142E >>> $0040142E >>> $00401441 >>> $00401441 >>> $00401441 >>> $00401441 >>> $00401441 >>> $00401441 >>> $00401441 >>> $00401441 >>> $00401441 >>> >>> (at a wild guess, it's run out of stack). I would say that it has >>> crashed. >> >> I went and looked. James was talking about pointers so a more direct >> example might be this: >> >> program copystring (output); >> procedure string_copy(var dst : string; src : string); >> begin >> dst := src >> end; >> var dp : ^string; >> begin >> string_copy(dp^, 'Hello World'); >> write(dp^) >> end. > > Part of the point that you could avoid using pointer in non-C > programming languages. There are constructs such as passing arguments > by reference, or using opaque objects (such as string) instead of bare > pointers to characters with some missing attribute such as allocated > size or length that must be passed on the side, which is propice to > errors, and ultimately crashes. > > When you are passing references in other languages, the underlying implementation is still passing around pointers. You can do the same in C - wrap your pointers inside structs, use access functions or macros. The difference is that in C you need to make these yourself and you don't get as neat syntax. Since you talk about "C programming languages" plural, are you including C++ ? In C++ you can pass by reference, make classes such as string, etc. - and you can get a result that is both faster and safer than with Pascal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-28 11:16 -0800 |
| Message-ID | <lnef8wy4mc.fsf@kst-u.example.com> |
| In reply to | #140354 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/01/2019 12:21, Pascal J. Bourguignon wrote:
[...]
>> Part of the point that you could avoid using pointer in non-C
>> programming languages. There are constructs such as passing arguments
>> by reference, or using opaque objects (such as string) instead of bare
>> pointers to characters with some missing attribute such as allocated
>> size or length that must be passed on the side, which is propice to
>> errors, and ultimately crashes.
[...]
> Since you talk about "C programming languages" plural, are you including
> C++ ? In C++ you can pass by reference, make classes such as string,
> etc. - and you can get a result that is both faster and safer than with
> Pascal.
He referred to "non-C programming languages, meaning all languages other
than C. He didn't mention "C programming languages".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-28 21:08 +0100 |
| Message-ID | <q2nnfc$tn6$1@dont-email.me> |
| In reply to | #140364 |
On 28/01/2019 20:16, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 28/01/2019 12:21, Pascal J. Bourguignon wrote: > [...] >>> Part of the point that you could avoid using pointer in non-C >>> programming languages. There are constructs such as passing arguments >>> by reference, or using opaque objects (such as string) instead of bare >>> pointers to characters with some missing attribute such as allocated >>> size or length that must be passed on the side, which is propice to >>> errors, and ultimately crashes. > [...] >> Since you talk about "C programming languages" plural, are you including >> C++ ? In C++ you can pass by reference, make classes such as string, >> etc. - and you can get a result that is both faster and safer than with >> Pascal. > > He referred to "non-C programming languages, meaning all languages other > than C. He didn't mention "C programming languages". > I mentally parsed it as (non)(C programming languages) rather than (non C)(programming languages), if you know what I mean. I was probably wrong, now that you point it out. However, it's not easy to be sure with a poster that writes Pascal when he means Lisp.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-28 01:19 +0100 |
| Message-ID | <m27eepeire.fsf@despina.home> |
| In reply to | #140335 |
Bart <bc@freeuk.com> writes:
> On 27/01/2019 23:51, Pascal J. Bourguignon wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>>> Let's break this down into pieces, so I can have some idea what it is
>>> you're claiming. Do you believe that it's impossible to write Pascal
>>> code that can crash? I know that's not what you said, but I want to
>>> cover all the possibilities.
>>
>> compare:
>>
>> void strcpy(char* dst,const char* src);
>>
>> with:
>>
>> procedure string_copy(var dst:string;src:string);
>>
>>
>> In C, you need a lot more information to be able to use the header.
>> In Pascal, you have all the information you need:
>>
>> var
>> dst:string;
>> begin
>> string_copy(dst,'Hello World');
>> end;
>>
>> will work without crashing.
>
> What would string_copy(dst, dst) do? What is the capacity of dst?
> (Last time I used Pascal, strings had to have a fixed length.)
That's the point: dst is not even allocated or initialised before
calling the function! it's a var parameter! It's string_copy that will
allocate it.
>> strcpy specifies pointers to a single char. We need to know what this
>> means. For example, that dst must be pointing to a block of memory of
>> size greater than strlen(src)+1.
>
> Yes, C is a lower level language.
>
> It's quite possible the implementation of your Pascal fragment will
> end up calling memcpy() to do the actual copying, which has the same
> issues as strcpy().
>
> Yet it won't crash; why not?
Good question. It won't crash because the constraints required to use
the low-level functions will be fulfilled by debugged primitive library
code, instead of the application programmer.
A lot of C functions take a pointer and a size (or a length; Hello
off-by-one errors!).
Instead they should take an object abstracting away those elements, so
that their consistency can be ensured by the functional abstraction.
strncpy(dst,src,size); /* crash ensured */
string_copy(dst,src); /* no crash possible, because string_copy
with handle all the cases, given
src->characters, src->length and
dst->characters, dst->allocated_size */
> These were the kinds of restrictions which made it hard to use Pascal
> for anything serious.
LOL
> You write a program to generate some machine code in a
> byte-array. Then you want to execute that code; how do you do it?
> (Ignore read-write-execute permissions; just to jump to it and
> return.)
You use a safe API defined to do it safely.
>> Note that you could define an abstract data type in C, and use it; then
>> the header declarations could be more self-contained.
>
> It is possible to write in a subset of C and avoid superfluous macros
> and typedefs to end up with clean-looking, readable and informative
> headers. But people don't always do that. (A lot of the time they are
> just masses of #ifs and #ifdefs and endless macros.)
Yep.
--
__Pascal J. Bourguignon__
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-27 16:59 -0800 |
| Message-ID | <lnr2cxy4uc.fsf@kst-u.example.com> |
| In reply to | #140337 |
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
[...]
> A lot of C functions take a pointer and a size (or a length; Hello
> off-by-one errors!).
>
> Instead they should take an object abstracting away those elements, so
> that their consistency can be ensured by the functional abstraction.
>
>
> strncpy(dst,src,size); /* crash ensured */
No, a crash is not ensured.
Here's a complete C program that includes that line:
#include <string.h>
#include <stdio.h>
int main(void) {
char dst[100];
const char *src = "hello, world";
const size_t size = sizeof dst;
strncpy(dst,src,size);
puts(dst);
}
It will not crash.
(I almost certainly wouldn't use strncpy myself, but that's not
the point. It's certainly possible to use strncpy in a way that
will cause a program to crash; that also is not the point.)
> string_copy(dst,src); /* no crash possible, because string_copy
> with handle all the cases, given
> src->characters, src->length and
> dst->characters, dst->allocated_size */
I don't believe there's a standard Pascal function called
"string_copy". In fact you can simply assign strings in Pascal:
dst := src;
What exactly are "src->characters", "src->length", and so forth? As far
as I can tell, Pascal doesn't use that syntax.
You assert that your string_copy procedure can't crash, but you haven't
shown us its implementation.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-27 16:33 -0800 |
| Message-ID | <lnva29y61z.fsf@kst-u.example.com> |
| In reply to | #140333 |
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
>> Assuming that it is possible to write
>> Pascal code that could crash, could you please provide an example?
>
> AFAICR, it's not possible to write a pascal program that could crash.
> A dereference of a null pointer, or an out of bounds indexing would be
> detected and the program would abort cleanly (or if error handling
> extensions are used, could be handled at run-time).
I haven't used Pascal in a long time, and I'm not as familiar with
the details of the standard as I am with C. Does an attempt to
dereference an uninitialized pointer have defined behavior in Pascal?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-28 01:35 +0100 |
| Message-ID | <m236pdei0g.fsf@despina.home> |
| In reply to | #140338 |
Keith Thompson <kst-u@mib.org> writes: > "Pascal J. Bourguignon" <pjb@informatimago.com> writes: >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >>> Assuming that it is possible to write >>> Pascal code that could crash, could you please provide an example? >> >> AFAICR, it's not possible to write a pascal program that could crash. >> A dereference of a null pointer, or an out of bounds indexing would be >> detected and the program would abort cleanly (or if error handling >> extensions are used, could be handled at run-time). > > I haven't used Pascal in a long time, and I'm not as familiar with > the details of the standard as I am with C. Does an attempt to > dereference an uninitialized pointer have defined behavior in Pascal? Well, I used pascal to avoid frightning you, but I actually meant lisp. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-27 17:20 -0800 |
| Message-ID | <lnmunly3wf.fsf@kst-u.example.com> |
| In reply to | #140339 |
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>>> Assuming that it is possible to write
>>>> Pascal code that could crash, could you please provide an example?
>>>
>>> AFAICR, it's not possible to write a pascal program that could crash.
>>> A dereference of a null pointer, or an out of bounds indexing would be
>>> detected and the program would abort cleanly (or if error handling
>>> extensions are used, could be handled at run-time).
>>
>> I haven't used Pascal in a long time, and I'm not as familiar with
>> the details of the standard as I am with C. Does an attempt to
>> dereference an uninitialized pointer have defined behavior in Pascal?
>
> Well, I used pascal to avoid frightning you, but I actually meant lisp.
I regret taking anything you've said in this thread seriously, and I'll
try to avoid making the same mistake in the future.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-27 22:50 -0500 |
| Message-ID | <q2lu5a$kbf$1@dont-email.me> |
| In reply to | #140342 |
On 1/27/19 20:20, Keith Thompson wrote: > "Pascal J. Bourguignon" <pjb@informatimago.com> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes: ... >>>> AFAICR, it's not possible to write a pascal program that could crash. >>>> A dereference of a null pointer, or an out of bounds indexing would be >>>> detected and the program would abort cleanly (or if error handling >>>> extensions are used, could be handled at run-time). >>> >>> I haven't used Pascal in a long time, and I'm not as familiar with >>> the details of the standard as I am with C. Does an attempt to >>> dereference an uninitialized pointer have defined behavior in Pascal? >> >> Well, I used pascal to avoid frightning you, but I actually meant lisp. > > I regret taking anything you've said in this thread seriously, and I'll > try to avoid making the same mistake in the future. Sounds like a good idea. I wonder if he's connected in any way to bpascal123, who had a similar style of thought?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-28 06:52 +0100 |
| Message-ID | <q2m5b0$kh4$1@dont-email.me> |
| In reply to | #140333 |
On 28/01/2019 00:51, Pascal J. Bourguignon wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>>>>> function compile_pascal(source:string):program;
>>>
>>> #include <string.h>
>>> int main(){
>>> char buf[3];
>>> strcpy(buf,"hello world, how do you do? fine, thank you.");
>>> return 0;}
>>>
>>> Abort trap: 6
>>
>> Let's break this down into pieces, so I can have some idea what it is
>> you're claiming. Do you believe that it's impossible to write Pascal
>> code that can crash? I know that's not what you said, but I want to
>> cover all the possibilities.
>
> compare:
>
> void strcpy(char* dst,const char* src);
>
> with:
>
> procedure string_copy(var dst:string;src:string);
>
>
> In C, you need a lot more information to be able to use the header.
In C, you have what you need (assuming the parameter names are given and
are accurate). A C "string" is a contiguous sequence of characters
terminated by a null character - usually accessed via a char* or const
char* pointer. You know src needs to point to a string, and you know
dst needs to point to enough space to store the copy of string.
> In Pascal, you have all the information you need:
>
> var
> dst:string;
> begin
> string_copy(dst,'Hello World');
> end;
>
> will work without crashing.
>
In Pascal, there are no standard string types. In practical Pascal
implementations, like Delphi or Free Pascal, there can easily be a dozen
string types. Some have fixed sizes, some have dynamic sizes. Some
have the length at the start, some have a trailing null for the length.
So no, in Pascal you /don't/ have all the information you need. But
there is a fair chance that "string" in this case refers to a fixed size
array of 255 characters preceded by a length byte. So this program
won't crash.
A program made from a series of string_cat calls could certainly fail,
however - just like with C, all you need to do is overflow the buffers.
>
>
> strcpy specifies pointers to a single char. We need to know what this
> means. For example, that dst must be pointing to a block of memory of
> size greater than strlen(src)+1.
>
>
>> Assuming that it is possible to write
>> Pascal code that could crash, could you please provide an example?
>
> AFAICR, it's not possible to write a pascal program that could crash.
Have you any experience at all with writing Pascal? I mean /real/
programs - actual working, useful programs? I won't deny that Pascal
has some useful features that help writer clearer and safer code than
you can easily do in C, but the idea that Pascal programs can't crash is
simply laughable.
> A dereference of a null pointer, or an out of bounds indexing would be
> detected and the program would abort cleanly (or if error handling
> extensions are used, could be handled at run-time).
How much run-time error checking you get depends on the compiler (or
p-code interpreter) and options you use. It is common in Pascal
development to have run-time checking flags enabled during development,
testing and debugging - that turns things like buffer overflows into
run-time errors (which are crashes, and are not "clean" - merely less
"dirty" than they might have been). It is common for deployed code to
disable these to avoid the overheads.
The same sort of thing is possible in C, though not nearly as common.
You can do so manually (with generous use of "assert", or access
functions for your data rather than direct use of arrays and pointers),
and many compilers support at least some kinds of run-time checking.
This kind of check makes it easier to find flaws in your code. It does
not magically make your incorrect code work.
>
>
>> I'm not sufficiently familiar with Pascal to come up with an example of my own.
>> Please humor me - this is just the first step in a series of questions
>> whose purpose will become clear when I gain a better understanding of
>> just what precisely it is you're claiming. The content of the later
>> questions will depend upon your answers to the earlier ones, which is
>> why I can't ask the whole thing at one time.
>
> Note that you could define an abstract data type in C, and use it; then
> the header declarations could be more self-contained.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-28 10:55 +0000 |
| Message-ID | <ycB3E.181298$XD1.131956@fx33.am4> |
| In reply to | #140346 |
On 28/01/2019 05:52, David Brown wrote:
> On 28/01/2019 00:51, Pascal J. Bourguignon wrote:
>> compare:
>>
>> void strcpy(char* dst,const char* src);
>>
>> with:
>>
>> procedure string_copy(var dst:string;src:string);
>>
>>
>> In C, you need a lot more information to be able to use the header.
>
> In C, you have what you need (assuming the parameter names are given and
> are accurate). A C "string" is a contiguous sequence of characters
> terminated by a null character - usually accessed via a char* or const
> char* pointer. You know src needs to point to a string, and you know
> dst needs to point to enough space to store the copy of string.
In C this information is all implied. A function to copy a single
character from one location to another could have a header like this:
void chrcpy(char* dst,const char* src);
Exactly the same as strcpy, apart from the name.
So it all comes down to documentation.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-28 12:26 +0100 |
| Message-ID | <m2lg35c9at.fsf@despina.home> |
| In reply to | #140348 |
Bart <bc@freeuk.com> writes: > On 28/01/2019 05:52, David Brown wrote: >> On 28/01/2019 00:51, Pascal J. Bourguignon wrote: > >>> compare: >>> >>> void strcpy(char* dst,const char* src); >>> >>> with: >>> >>> procedure string_copy(var dst:string;src:string); >>> >>> >>> In C, you need a lot more information to be able to use the header. >> >> In C, you have what you need (assuming the parameter names are given >> and are accurate). A C "string" is a contiguous sequence of >> characters terminated by a null character - usually accessed via a >> char* or const char* pointer. You know src needs to point to a >> string, and you know dst needs to point to enough space to store the >> copy of string. > > In C this information is all implied. A function to copy a single > character from one location to another could have a header like this: > > void chrcpy(char* dst,const char* src); > > Exactly the same as strcpy, apart from the name. > > So it all comes down to documentation. Yes, exactly my point. Said documentation, be it in comments or in separate documents, being bound to be outdated, wrong, or inexistant. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-28 13:27 +0100 |
| Message-ID | <q2msgb$ffv$2@dont-email.me> |
| In reply to | #140352 |
On 28/01/2019 12:26, Pascal J. Bourguignon wrote: > Bart <bc@freeuk.com> writes: > >> On 28/01/2019 05:52, David Brown wrote: >>> On 28/01/2019 00:51, Pascal J. Bourguignon wrote: >> >>>> compare: >>>> >>>> void strcpy(char* dst,const char* src); >>>> >>>> with: >>>> >>>> procedure string_copy(var dst:string;src:string); >>>> >>>> >>>> In C, you need a lot more information to be able to use the header. >>> >>> In C, you have what you need (assuming the parameter names are given >>> and are accurate). A C "string" is a contiguous sequence of >>> characters terminated by a null character - usually accessed via a >>> char* or const char* pointer. You know src needs to point to a >>> string, and you know dst needs to point to enough space to store the >>> copy of string. >> >> In C this information is all implied. A function to copy a single >> character from one location to another could have a header like this: >> >> void chrcpy(char* dst,const char* src); >> >> Exactly the same as strcpy, apart from the name. >> >> So it all comes down to documentation. > > Yes, exactly my point. Said documentation, be it in comments or in > separate documents, being bound to be outdated, wrong, or inexistant. > The "documentation" in this case is in the name of the function and its parameters' types and names. At some level, you have to expect the programmer to be competent at choosing that sort of thing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-28 13:26 +0100 |
| Message-ID | <q2mse6$ffv$1@dont-email.me> |
| In reply to | #140348 |
On 28/01/2019 11:55, Bart wrote: > On 28/01/2019 05:52, David Brown wrote: >> On 28/01/2019 00:51, Pascal J. Bourguignon wrote: > >>> compare: >>> >>> void strcpy(char* dst,const char* src); >>> >>> with: >>> >>> procedure string_copy(var dst:string;src:string); >>> >>> >>> In C, you need a lot more information to be able to use the header. >> >> In C, you have what you need (assuming the parameter names are given >> and are accurate). A C "string" is a contiguous sequence of >> characters terminated by a null character - usually accessed via a >> char* or const char* pointer. You know src needs to point to a >> string, and you know dst needs to point to enough space to store the >> copy of string. > > In C this information is all implied. A function to copy a single > character from one location to another could have a header like this: > > void chrcpy(char* dst,const char* src); > > Exactly the same as strcpy, apart from the name. > > So it all comes down to documentation. > Agreed. In /all/ programming, documentation (and naming) is critical to knowing what is happening, and what a function will do. While many languages do a much better job of distinguishing between "pointer to an object" and "pointer to some objects" than C does, pretty much any language relies on naming and documentation to distinguish: int add(int x, int y); and int mult(int x, int y);
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web