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 | 11 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 4 of 4 — ← Prev page 1 2 3 [4]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-28 14:03 +0100 |
| Message-ID | <m2ef8xc4tw.fsf@despina.home> |
| In reply to | #140355 |
David Brown <david.brown@hesbynett.no> writes:
> 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);
Note that even without documentation, we may assume that:
assert(4==add(2,2));
assert(4==mult(2,2));
--
__Pascal J. Bourguignon__
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-28 11:12 -0800 |
| Message-ID | <lnimy8y4sy.fsf@kst-u.example.com> |
| In reply to | #140348 |
Bart <bc@freeuk.com> writes:
[...]
> 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.
There would be no point in making src a const char* rather than simply a
char.
There also would be no point in making chrcpy a function rather than
using a simple assignment (unless chrcpy needs to do more than simply
copying a character value).
> So it all comes down to documentation.
--
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 12:25 +0100 |
| Message-ID | <m2pnshc9ce.fsf@despina.home> |
| In reply to | #140346 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-28 13:33 +0100 |
| Message-ID | <q2msqm$i0m$1@dont-email.me> |
| In reply to | #140351 |
On 28/01/2019 12:25, Pascal J. Bourguignon wrote:
> 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.
>
It's been a good while since I have done much Pascal programming too,
but I think it is worth refreshing a little before making outlandish
claims about it.
>
>>> 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…
>
In my Pascal programming, I disabled run-time checking once my code was
solid enough - except while bug-hunting or doing stress tests. I don't
knowingly release code with bugs in it - and unnecessary run-time
checking is thus simply a drain on resources. (This would depend on the
speed requirements of the program in question.) The same is true for my
C coding.
I don't distinguish between "production" and "debug" builds. I
distinguish between "early development" and "late development" builds,
and "bug-hunting" 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.
>
I use abstract data types in C.
Certainly Pascal lets you make types in a variety of ways that are not
possible or convenient in C, but that does not mean you can't do safe
and reliable programming in C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-28 11:20 -0800 |
| Message-ID | <lna7jky4fe.fsf@kst-u.example.com> |
| In reply to | #140346 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.
ISO 7185:1990, the ISO Pascal standard, disagrees with you.
--
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:11 +0100 |
| Message-ID | <q2nnmf$1b5$1@dont-email.me> |
| In reply to | #140365 |
On 28/01/2019 20:20, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> 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. > > ISO 7185:1990, the ISO Pascal standard, disagrees with you. > OK, there is no standard string type that is actually used, in practical Pascal dialects. AFAIK, the Pascal ISO standard is pretty much ignored by all Pascal implementations that are used for real-world coding, which mostly derive from Borland Pascal heritage. (Perhaps I am being overly cynical here - if anyone knows better, I would be happy to be corrected.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-01-28 21:12 +0000 |
| Message-ID | <efK3E.89053$C64.29740@fx21.iad> |
| In reply to | #140367 |
David Brown <david.brown@hesbynett.no> writes:
>On 28/01/2019 20:20, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> 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.
>>
>> ISO 7185:1990, the ISO Pascal standard, disagrees with you.
>>
>
>OK, there is no standard string type that is actually used, in practical
>Pascal dialects. AFAIK, the Pascal ISO standard is pretty much ignored
>by all Pascal implementations that are used for real-world coding, which
>mostly derive from Borland Pascal heritage.
>
>(Perhaps I am being overly cynical here - if anyone knows better, I
>would be happy to be corrected.)
>
Dunno - last time I used Pascal was circa 1982 on a VAX 11/780. No strings,
but that predates the standard Keith referred to. Oddly, one of the pascal
string manipulation programs I found in my early archives (written by a colleague
whom I hear is now at RedHat) defines its first set of strings like this:
value
{funct_array is initialized to the following values. Each
string is a packed array of length 20. These strings represent
the predefined functions.}
funct_array := ( 'CAR ', {1}
'CDR ', {2}
'CONS ', {3}
'MAPCAR ', {4}
'RPLACA ', {5}
'RPLACD ', {6}
I'll give you one guess as to the program purpose :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-28 23:06 +0100 |
| Message-ID | <q2nucu$at2$1@dont-email.me> |
| In reply to | #140368 |
On 28/01/2019 22:12, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/01/2019 20:20, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> 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.
>>>
>>> ISO 7185:1990, the ISO Pascal standard, disagrees with you.
>>>
>>
>> OK, there is no standard string type that is actually used, in practical
>> Pascal dialects. AFAIK, the Pascal ISO standard is pretty much ignored
>> by all Pascal implementations that are used for real-world coding, which
>> mostly derive from Borland Pascal heritage.
>>
>> (Perhaps I am being overly cynical here - if anyone knows better, I
>> would be happy to be corrected.)
>>
>
> Dunno - last time I used Pascal was circa 1982 on a VAX 11/780. No strings,
> but that predates the standard Keith referred to. Oddly, one of the pascal
> string manipulation programs I found in my early archives (written by a colleague
> whom I hear is now at RedHat) defines its first set of strings like this:
>
> value
> {funct_array is initialized to the following values. Each
> string is a packed array of length 20. These strings represent
> the predefined functions.}
> funct_array := ( 'CAR ', {1}
> 'CDR ', {2}
> 'CONS ', {3}
> 'MAPCAR ', {4}
> 'RPLACA ', {5}
> 'RPLACD ', {6}
>
> I'll give you one guess as to the program purpose :-)
>
Maybe we should let this thread's Lisp fan guess?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-27 15:02 +0100 |
| Message-ID | <q2kdm1$j9n$1@dont-email.me> |
| In reply to | #140305 |
On 26/01/2019 21:39, Joe Pfeiffer wrote: > Mateusz Viste <mateusz@wont.tell> writes: > >> On Fri, 25 Jan 2019 19:43:44 -0700, Joe Pfeiffer wrote: >>> When I have a need to actually read a header file, things have already >>> gone completely egg-shaped. That's only one step away from using the >>> dreaded -E flag to gcc. >> >> Well, if you had read the headers before playing with the library, >> perhaps things wouldn't go egg-shaped in the first place. >> Documentation is cool of course, but it's often incomplete, not up to >> date, or entirely missing. Source code is the reference. And source code >> functions are declared through headers. > > You really think > > /* Copy SRC to DEST. */ > extern char *strcpy (char *__restrict __dest, const char *__restrict __src) > __THROW __nonnull ((1, 2)); > > is going to tell me more about strcpy than looking at the man page? > > Yes, the documentation may be out of date, inaccurate, or missing. But > you're going to get a lot farther by starting with the assumption that > it's right and working with that assumption until you find something > that isn't working than by reading headers with their terse at best > comments in order to try to guess how to use a library. > For some libraries, there is good documentation, and the headers are complicated - that applies to the C standard library, for example. For other libraries, documentation can be poor and headers clear, and then headers are your main source of information about using the code. (Of course, in some cases, documentation is poor and the headers are jumbled.) If you want to look at headers, you can make life far easier for yourself with a good IDE. That will let you navigate quickly between parts, show the definitions of macros with tool-tips, make conditional compilation sections obvious by different colouring for the parts that are used or unused.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 17:51 +0100 |
| Message-ID | <m2pnskfzon.fsf@despina.home> |
| In reply to | #140262 |
Thiago Adams <thiago.adams@gmail.com> writes: > On Friday, January 25, 2019 at 1:23:16 PM UTC-2, Malcolm McLean wrote: >> Here's a site for C header only libraries. >> (You use a hash define to toggle compilation of the executable code, >> so the same file is both header and implementation) >> >> The one file rule is certainly handy. >> >> https://github.com/vurtun/mmx > > I think header only makes sense for C++ templates and some > inline functions. > > For C, I think a pair .c and .h makes more sense. Well, the point is that there is a lot of _library_ code that wants to be "generic", and that means in C, that it is actually defined and expanded from preprocessor macros. This can be done only in the headers. Notably, the type system of C is so defective that you need to ensure type safety, (the little that C provides), to duplicate a lot of code. Using void* is completely unsatisfactory, on the both sides of an API. Perhaps a better question to ask, is why you would want to use libraries in C, when you can write programs in Objective-C or other high level OO programming languages? -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-25 14:28 -0800 |
| Message-ID | <b31b3a01-723b-4076-be6d-b7adc9f5ee77@googlegroups.com> |
| In reply to | #140262 |
W dniu piątek, 25 stycznia 2019 16:31:54 UTC+1 użytkownik Thiago Adams napisał: > On Friday, January 25, 2019 at 1:23:16 PM UTC-2, Malcolm McLean wrote: > > Here's a site for C header only libraries. > > (You use a hash define to toggle compilation of the executable code, > > so the same file is both header and implementation) > > > > The one file rule is certainly handy. > > > > https://github.com/vurtun/mmx > > I think header only makes sense for C++ templates and some > inline functions. > > For C, I think a pair .c and .h makes more sense. in fact not .h not pair .c .h makes sense but rather .c file makes sense imo in my case i rather use N of .c files, becouse when library is liek a book such sperate .c files are liek chapters of that book, (and one 'master' file with includes of that files is liek table of contents of that book) .c file is a basic fundamental way of organising .c codes and it is not to just be skipped/denayed so, pack of N .c files in my case (when doing open cource) or .dll with a .h header when doing closed source
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web