Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140351
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Distributing C as headers. |
| Date | 2019-01-28 12:25 +0100 |
| Organization | Informatimago |
| Message-ID | <m2pnshc9ce.fsf@despina.home> (permalink) |
| References | (11 earlier) <ln8sz7yrq4.fsf@kst-u.example.com> <m2imybdp04.fsf@despina.home> <q2l6r5$suk$1@dont-email.me> <m2bm41ek17.fsf@despina.home> <q2m5b0$kh4$1@dont-email.me> |
David Brown <david.brown@hesbynett.no> writes:
> 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.
Well it has been a long time since I wrote a pascal program. I actually
used it before I had to use C.
>> 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.
For a C programmer perhaps… I guess you remove all the -fsanity options
from your production builds…
> 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.
Indeed. But again, notice that it is easier or even just possible to
insert those manual checks only if you have been using abstract data
types, not if you keep calling functions that take pointers and green
data as parameters.
--
__Pascal J. Bourguignon__
http://www.informatimago.com
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web