Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #140261 > unrolled thread

Distributing C as headers.

Back to article view | Back to comp.lang.c

Contents

  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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#141508

Jason C. McDonald wrote:

> nobody@example.org (Scott) writes:
>  
>> On Sat, 26 Jan 2019 22:29:12 +0100, "Pascal J. Bourguignon"
>> <pjb@informatimago.com> wrote:
>>
>> We need a new programming language that is inherently self-documenting,
>> using simple (dare I say, common?) verbiage, perhaps at first oriented
>> towards business computing.
> 
> Wasn't that the entire purpose of Donald Knuth's CWEB? Mind you, I've
> never actually used it. I'm not afraid of writing documentation.

I don't know about that, but I am certain that <<nobody>> is thinking more 
along the lines of the results of CODASYL's 1968 Conference on Data System 
Languages that Rear Admiral Hopper particapated in.

You know, the Common Business-Oriented Language that runs most of the 
world's backend systems.  ;-)

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#141510

"Jason C. McDonald" <indeliblebluepen@gmail.com> writes:

> nobody@example.org (Scott) writes:
>  
>> On Sat, 26 Jan 2019 22:29:12 +0100, "Pascal J. Bourguignon"
>> <pjb@informatimago.com> wrote:
>>
>> We need a new programming language that is inherently self-documenting,
>> using simple (dare I say, common?) verbiage, perhaps at first oriented
>> towards business computing.

I never wrote that!  Learn how to quote properly!

> Wasn't that the entire purpose of Donald Knuth's CWEB? Mind you, I've 
> never actually used it. I'm not afraid of writing documentation.


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#141514

On Thursday, February 28, 2019 at 3:40:52 PM UTC-5, Pascal J. Bourguignon wrote:
> "Jason C. McDonald" <indeliblebluepen@gmail.com> writes:
> 
> > nobody@example.org (Scott) writes:
> >  
> >> On Sat, 26 Jan 2019 22:29:12 +0100, "Pascal J. Bourguignon"
> >> <pjb@informatimago.com> wrote:
> >>
> >> We need a new programming language that is inherently self-documenting,
> >> using simple (dare I say, common?) verbiage, perhaps at first oriented
> >> towards business computing.
> 
> I never wrote that!  Learn how to quote properly!

Per standard quotation syntax, Jason's message doesn't attribute any of
the quoted material to you. The lines associated with each attribution
are supposed to be indented one level relative to the attribution
itself. Jason copied Scott's attribution line for you, and correctly
indented it one level, but he snipped all of the text associated with
that line. None of the text he did quote is indented in a way that
connects it with that attribution. That renders that attribution line
pointless and confusing, but it's not actually incorrect.
The indentation of the lines starting with "We need ..." indicate that
they are associated with the attribution line for Scott, not the
attribution line for you.
He did fail to mark his snippage, but he didn't misattribute anything.

[toc] | [prev] | [next] | [standalone]

#140322

On Sat, 2019-01-26, Mateusz Viste wrote:
> On Sat, 26 Jan 2019 13:39:34 -0700, Joe Pfeiffer wrote:
>> 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?
>
> You picked a specific example. The libc documentation is awesomely 
> accurate, and declarations tend to be messy. For such obviously standard 
> things, documentation is the way to go. For anything less ubiquitous, 
> looking at the header may provide very useful knowledge. This, for 
> example, is an extract from the header file of the tinf library:
>
> /**
>  * Decompress `sourceLen` bytes of deflate data from `source` to `dest`.
>  *
>  * The variable `destLen` points to must contain the size of `dest` on
>  * entry, and will be set to the size of the decompressed data on success.
>  *
>  * Reads at most `sourceLen` bytes from `source`.
>  * Writes at most `*destLen` bytes to `dest`.
>  *
>  * @param dest pointer to where to place decompressed data
>  * @param destLen pointer to variable containing size of `dest`
>  * @param source pointer to compressed data
>  * @param sourceLen size of compressed data
>  * @return `TINF_OK` on success, error code on error
>  */
> int TINFCC tinf_uncompress(void *dest, unsigned int *destLen,
> const void *source, unsigned int sourceLen);
>
> Isn't it delicious?
> With proper headers, documentation becomes useless.

But that /is/ documentation!  I'd be overjoyed to find a library with
that kind of documentation, /either/ as man pages or as a well-crafted
header file.

(BTW, that documentation also shows nicely how pointless @param lists
are.  This one adds nothing to the very readable description above,
and isn't enough in itself.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#140325

On 26/01/2019 22:00, Mateusz Viste wrote:
> On Sat, 26 Jan 2019 13:39:34 -0700, Joe Pfeiffer wrote:
>> 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?
> 
> You picked a specific example. The libc documentation is awesomely
> accurate, and declarations tend to be messy. For such obviously standard
> things, documentation is the way to go. For anything less ubiquitous,
> looking at the header may provide very useful knowledge. This, for
> example, is an extract from the header file of the tinf library:
> 
> /**
>   * Decompress `sourceLen` bytes of deflate data from `source` to `dest`.
>   *
>   * The variable `destLen` points to must contain the size of `dest` on
>   * entry, and will be set to the size of the decompressed data on success.
>   *
>   * Reads at most `sourceLen` bytes from `source`.
>   * Writes at most `*destLen` bytes to `dest`.
>   *
>   * @param dest pointer to where to place decompressed data
>   * @param destLen pointer to variable containing size of `dest`
>   * @param source pointer to compressed data
>   * @param sourceLen size of compressed data
>   * @return `TINF_OK` on success, error code on error
>   */
> int TINFCC tinf_uncompress(void *dest, unsigned int *destLen,
> const void *source, unsigned int sourceLen);
> 
> Isn't it delicious?
> With proper headers, documentation becomes useless.
> 
> Mateusz
> 

With headers like that, documentation is still not useless - 
documentation can include overviews, examples, tutorials, etc., as well 
as the specifications of individual functions.  The code you quoted here 
looks like it is ready for doxygen, which is perhaps the ideal balance 
between headers and documentation.  Your headers have reasonable 
documentation in a convenient place, and you can automatically extract 
and generate fuller documentation in useful formats - guaranteed to be 
in sync with the actual code.

[toc] | [prev] | [next] | [standalone]

#140307

On Saturday, January 26, 2019 at 2:39:43 PM UTC-6, 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.

I can see valid points on both side here, but you both appear to be citing
extreme examples and then trying to generalize from there. 

In the general, general case one should consult the documentation first,
and consult the header files if necessary. The real documentation should
obviously be the first step. But IME and that of others, the documentation
may be inaccurate, incomplete, or otherwise inadequate.

As a personal anecdote, some years ago I was using the Cairo library to
render polygons and whatnot. And everything related to polygons and paths
was nicely laid out in the manual. But later when I needed to render 
bitmaps and nibble-maps and bytemaps, the necessary information about
Cairo's in-memory formats was not in the manual anywhere. Only in the 
headers.

This is just a single data point, of course. But it seems to be a not-
impossible situation to expect in the future.

[toc] | [prev] | [next] | [standalone]

#140310

luser droog <luser.droog@gmail.com> writes:

> As a personal anecdote, some years ago I was using the Cairo library to
> render polygons and whatnot. And everything related to polygons and paths
> was nicely laid out in the manual. But later when I needed to render 
> bitmaps and nibble-maps and bytemaps, the necessary information about
> Cairo's in-memory formats was not in the manual anywhere. Only in the 
> headers.
>
> This is just a single data point, of course. But it seems to be a not-
> impossible situation to expect in the future.

IME, this is the rule.

Some vendors invest more effort to write good documentation, but it's
never exhaustive.


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#140479

On Sat, 2019-01-26, Pascal J. Bourguignon wrote:
> luser droog <luser.droog@gmail.com> writes:
>
>> As a personal anecdote, some years ago I was using the Cairo library to
>> render polygons and whatnot. And everything related to polygons and paths
>> was nicely laid out in the manual. But later when I needed to render 
>> bitmaps and nibble-maps and bytemaps, the necessary information about
>> Cairo's in-memory formats was not in the manual anywhere. Only in the 
>> headers.
>>
>> This is just a single data point, of course. But it seems to be a not-
>> impossible situation to expect in the future.
>
> IME, this is the rule.
>
> Some vendors invest more effort to write good documentation, but it's
> never exhaustive.

I'm baffled by people who feel it's worth their time to write code to
be used by others, but not provide the information needed to use it.

Often what's missing is mostly a rather brief text explaining the
metaphors, the strategies for error handling and resource management,
and the limits of the problem.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#140308

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

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

Well, in my book, if the declaration of the object is not enough to be
able to use it, and requires a separate English documentation, this is a
defect in the language.  Note that I don't say, "able to use it
effectively", just "able to use it".

For example, having a function declaration such as:

   type program = …;
   function compile_pascal(source:string):program;

let you use it.

But if you use it with random strings, you may only get error messages
or other useless results:

   var p:program;
   begin
      p:=compile_pascal("Hello World");
      execute_pascal(p);
   end;


So you may have to read some documentation to use it effectively, such
as form example, a documentation indicating the syntax and semantics of
the valid data:

   var p:program;
   begin
      p:=compile_pascal("program hw; begin writeln('Hello World'); end;")
      execute_pascal(p);
   end;


However the important part is that from the mere reading of the
header/interface/definition module, you can write a program using the
defined object that can run without crashing.

(Obviously, I used pascal for my example, since it is not possible in C).

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#140312

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
[...]
> Well, in my book, if the declaration of the object is not enough to be
> able to use it, and requires a separate English documentation, this is a
> defect in the language.  Note that I don't say, "able to use it
> effectively", just "able to use it".
>
> For example, having a function declaration such as:
>
>    type program = …;
>    function compile_pascal(source:string):program;
>
> let you use it.

Does it?  Is the source parameter a representation of Pascal source
code, or the name of a file containing Pascal source code?

[...]
> However the important part is that from the mere reading of the
> header/interface/definition module, you can write a program using the
> defined object that can run without crashing.
>
> (Obviously, I used pascal for my example, since it is not possible in C).

Just what it is that you're saying is not possible in C?

    typedef ... program;
    program compile_c(const char *source); // or compile_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]

#140313

Keith Thompson <kst-u@mib.org> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> [...]
>> Well, in my book, if the declaration of the object is not enough to be
>> able to use it, and requires a separate English documentation, this is a
>> defect in the language.  Note that I don't say, "able to use it
>> effectively", just "able to use it".
>>
>> For example, having a function declaration such as:
>>
>>    type program = …;
>>    function compile_pascal(source:string):program;
>>
>> let you use it.
>
> Does it?  Is the source parameter a representation of Pascal source
> code, or the name of a file containing Pascal source code?

Again, I didn't say "let you use it effectively".  I said "let you use
it (without crashing)".


> [...]
>> However the important part is that from the mere reading of the
>> header/interface/definition module, you can write a program using the
>> defined object that can run without crashing.
>>
>> (Obviously, I used pascal for my example, since it is not possible in C).
>
> Just what it is that you're saying is not possible in C?
>
>     typedef ... program;
>     program compile_c(const char *source); // or compile_pascal

It is not possible to write a program that won't crash in C, based only
on the declarations.


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#140314

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> [...]
>>> Well, in my book, if the declaration of the object is not enough to be
>>> able to use it, and requires a separate English documentation, this is a
>>> defect in the language.  Note that I don't say, "able to use it
>>> effectively", just "able to use it".
>>>
>>> For example, having a function declaration such as:
>>>
>>>    type program = …;
>>>    function compile_pascal(source:string):program;
>>>
>>> let you use it.
>>
>> Does it?  Is the source parameter a representation of Pascal source
>> code, or the name of a file containing Pascal source code?
>
> Again, I didn't say "let you use it effectively".  I said "let you use
> it (without crashing)".

Ok.  So what is the point of being able to use a function ineffectively?

>> [...]
>>> However the important part is that from the mere reading of the
>>> header/interface/definition module, you can write a program using the
>>> defined object that can run without crashing.
>>>
>>> (Obviously, I used pascal for my example, since it is not possible in C).
>>
>> Just what it is that you're saying is not possible in C?
>>
>>     typedef ... program;
>>     program compile_c(const char *source); // or compile_pascal
>
> It is not possible to write a program that won't crash in C, based only
> on the declarations.

How do you reach that conclusion?

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

#140315

Keith Thompson <kst-u@mib.org> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>> [...]
>>>> Well, in my book, if the declaration of the object is not enough to be
>>>> able to use it, and requires a separate English documentation, this is a
>>>> defect in the language.  Note that I don't say, "able to use it
>>>> effectively", just "able to use it".
>>>>
>>>> For example, having a function declaration such as:
>>>>
>>>>    type program = …;
>>>>    function compile_pascal(source:string):program;
>>>>
>>>> let you use it.
>>>
>>> Does it?  Is the source parameter a representation of Pascal source
>>> code, or the name of a file containing Pascal source code?
>>
>> Again, I didn't say "let you use it effectively".  I said "let you use
>> it (without crashing)".
>
> Ok.  So what is the point of being able to use a function ineffectively?

Explorability.

But notice that most functions that can be used, can be used
effectively.  Those that cannot, that need documentation, are rather
rare and have special characteristics.  They also usually require a lot
of documentation.



>>> [...]
>>>> However the important part is that from the mere reading of the
>>>> header/interface/definition module, you can write a program using the
>>>> defined object that can run without crashing.
>>>>
>>>> (Obviously, I used pascal for my example, since it is not possible in C).
>>>
>>> Just what it is that you're saying is not possible in C?
>>>
>>>     typedef ... program;
>>>     program compile_c(const char *source); // or compile_pascal
>>
>> It is not possible to write a program that won't crash in C, based only
>> on the declarations.
>
> How do you reach that conclusion?

#include <string.h>
int main(){
    char buf[3];
    strcpy(buf,"hello world, how do you do? fine, thank you.");
    return 0;}
    
Abort trap: 6


Existance proofs are easy…

    
-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#140316

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>>> [...]
>>>>> Well, in my book, if the declaration of the object is not enough to be
>>>>> able to use it, and requires a separate English documentation, this is a
>>>>> defect in the language.  Note that I don't say, "able to use it
>>>>> effectively", just "able to use it".
>>>>>
>>>>> For example, having a function declaration such as:
>>>>>
>>>>>    type program = …;
>>>>>    function compile_pascal(source:string):program;
>>>>>
>>>>> let you use it.
>>>>
>>>> Does it?  Is the source parameter a representation of Pascal source
>>>> code, or the name of a file containing Pascal source code?
>>>
>>> Again, I didn't say "let you use it effectively".  I said "let you use
>>> it (without crashing)".
>>
>> Ok.  So what is the point of being able to use a function ineffectively?
>
> Explorability.
>
> But notice that most functions that can be used, can be used
> effectively.  Those that cannot, that need documentation, are rather
> rare and have special characteristics.  They also usually require a lot
> of documentation.

I disagree.  And in any case, your hand-picked example can't be used
effectively without more documentation.

>>>> [...]
>>>>> However the important part is that from the mere reading of the
>>>>> header/interface/definition module, you can write a program using the
>>>>> defined object that can run without crashing.
>>>>>
>>>>> (Obviously, I used pascal for my example, since it is not possible in C).
>>>>
>>>> Just what it is that you're saying is not possible in C?
>>>>
>>>>     typedef ... program;
>>>>     program compile_c(const char *source); // or compile_pascal
>>>
>>> It is not possible to write a program that won't crash in C, based only
>>> on the declarations.
>>
>> How do you reach that conclusion?
>
> #include <string.h>
> int main(){
>     char buf[3];
>     strcpy(buf,"hello world, how do you do? fine, thank you.");
>     return 0;}
>     
> Abort trap: 6
>
>
> Existance proofs are easy…

Of course they are.  You're proven that it's possible to write a
C program that will (probably) crash.  (It has undefined behavior,
and could execute with no visible problems, but it does crash under
most of the implementations I tried.)

I don't see what that has to do with your claim, that "It is not
possible to write a program that won't crash in C, based only on
the declarations."

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

#140327

On 26/01/2019 23:37, Pascal J. Bourguignon wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
<snip>
>>>
>>> It is not possible to write a program that won't crash in C, based only
>>> on the declarations.
>>
>> How do you reach that conclusion?
> 
> #include <string.h>
> int main(){
>      char buf[3];
>      strcpy(buf,"hello world, how do you do? fine, thank you.");
>      return 0;}
>      
> Abort trap: 6
> 
> 
> Existance proofs are easy…
> 


Existence proofs are often easy - you have given proof that you can 
write a program in C that crashes.

Non-existence proofs are often harder - you claimed that you can't write 
a program in C that won't crash ("based only on the declarations", 
whatever that might mean).  It's easy to prove your claim is invalid, 
just by writing a program in C that does not crash:

int main(void) {
	return 0;
}

If you want to make absurd claims, at least try /slightly/ harder to 
back them up.

[toc] | [prev] | [next] | [standalone]

#140330

On 1/26/19 17:37, Pascal J. Bourguignon wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>>> [...]
>>>>> Well, in my book, if the declaration of the object is not enough to be
>>>>> able to use it, and requires a separate English documentation, this is a
>>>>> defect in the language.  Note that I don't say, "able to use it
>>>>> effectively", just "able to use it".
>>>>>
>>>>> For example, having a function declaration such as:
>>>>>
>>>>>    type program = …;
>>>>>    function compile_pascal(source:string):program;
>>>>>
>>>>> let you use it.
>>>>
>>>> Does it?  Is the source parameter a representation of Pascal source
>>>> code, or the name of a file containing Pascal source code?
>>>
>>> Again, I didn't say "let you use it effectively".  I said "let you use
>>> it (without crashing)".
>>
>> Ok.  So what is the point of being able to use a function ineffectively?
> 
> Explorability.
> 
> But notice that most functions that can be used, can be used
> effectively.  Those that cannot, that need documentation, are rather
> rare and have special characteristics.  They also usually require a lot
> of documentation.
> 
> 
> 
>>>> [...]
>>>>> However the important part is that from the mere reading of the
>>>>> header/interface/definition module, you can write a program using the
>>>>> defined object that can run without crashing.
>>>>>
>>>>> (Obviously, I used pascal for my example, since it is not possible in C).
>>>>
>>>> Just what it is that you're saying is not possible in C?
>>>>
>>>>     typedef ... program;
>>>>     program compile_c(const char *source); // or compile_pascal
>>>
>>> It is not possible to write a program that won't crash in C, based only
>>> on the declarations.
>>
>> How do you reach that conclusion?
> 
> #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. Assuming that it is possible to write
Pascal code that could crash, could you please provide an example? 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.

[toc] | [prev] | [next] | [standalone]

#140333

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 Pascal, you have all the information you need:

   var
      dst:string;
   begin
     string_copy(dst,'Hello World');
   end;

will work without crashing.
    


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


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#140335

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

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

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

These were the kinds of restrictions which made it hard to use Pascal 
for anything serious.

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

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

[toc] | [prev] | [next] | [standalone]

#140336

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.

[toc] | [prev] | [next] | [standalone]

#140341

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.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web