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

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

Dropping C

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

Contents

  Dropping C bartc <bc@freeuk.com> - 2018-03-17 16:07 +0000
    Re: Dropping C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-18 00:41 +0800
    Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 19:54 -0400
      Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-18 13:19 +1300
        Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 02:42 -0700
      Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 01:28 +0000
        Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 21:41 -0400
          Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 11:25 +0000
            Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 04:33 -0700
            Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-19 00:05 +0100
              Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 00:24 +0000
                Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-18 21:15 -0400
                  Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 19:00 -0700
                  Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 14:04 +0100
                    Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:08 -0700
                    Re: Dropping C supercat@casperkitty.com - 2018-03-19 14:29 -0700
                Re: Dropping C Noob <root@127.0.0.1> - 2018-03-19 14:34 +0100
                  Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:39 -0700
                  Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 15:17 +0100
                    Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:03 +0000
                      Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:36 +0000
                        Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:01 +0000
                          Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 12:14 -0600
                            Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 19:15 +0000
                              Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 08:20 +1300
                                Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 20:47 +0000
                                  Re: Dropping C Lowell Gilbert <lgusenet@be-well.ilk.org> - 2018-03-19 18:00 -0400
                                    Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 22:17 +0000
                                      Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:34 +0800
                                      Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 07:54 +0100
                                        Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-21 04:10 -0500
                                          Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:08 +0000
                                            Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:18 +0000
                                              Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 05:28 -0700
                                        Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 12:13 +0000
                                          Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:26 +0000
                                            Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 15:55 +0000
                                          Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:15 +0100
                                            Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-21 12:45 -0700
                                              Re: Dropping C supercat@casperkitty.com - 2018-03-21 13:46 -0700
                                              Killfiles (Was: Dropping C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-03-21 21:42 +0000
                                                Re: Killfiles (Was: Dropping C) Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-22 04:22 -0700
                                            Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 20:21 +0000
                                            Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 22:21 -0700
                                    Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:32 +0800
                                Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 10:01 +1300
                                  Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-20 16:01 -0700
                              Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 13:41 -0600
                              Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-19 12:52 -0700
                              Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-19 20:15 +0000
                              Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 20:38 +0000
                                Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 22:00 +0100
                                  Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:45 +0000
                                    Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:05 +0100
                                Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:09 +0000
                                  Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 18:26 +1300
                                    Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 10:58 +0000
                                      Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:22 +0100
                                        Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 13:58 +0000
                                          Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 17:14 +0100
                                          Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 16:31 +0000
                                            Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 17:14 +0000
                                      Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 07:31 +1300
                                        Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 18:51 +0000
                                          Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:01 +1300
                                          Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:03 +0000
                                            Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:22 +0000
                                              Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:25 +1300
                                                Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:33 +0000
                                                  Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 09:34 +1300
                                              Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:49 +0000
                                            Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-21 11:27 +0100
                                Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:27 +0000
                      Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 17:03 +0100
                        Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:13 +0100
                          Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 00:23 +0100
                        Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 00:55 +0000
                          Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 02:29 +0100
                            Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:04 +0000
                              Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:31 +0100
                            Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:18 +0100
                              Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 21:32 +0100
                                Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-21 20:52 +0000
                                  Re: Dropping C supercat@casperkitty.com - 2018-03-21 14:38 -0700
                                    Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 23:08 +0100
                                      Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-22 13:37 +0000
                                        Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 15:41 +0100
                                          Re: Dropping C bartc <bc@freeuk.com> - 2018-03-22 14:58 +0000
                                            Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 17:37 +0100
                                              Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:09 +0000
                                                Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:27 +0100
                                                  Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:35 +0000
                                                    Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:46 +0100
                                                      Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 18:22 +0000
                                                        Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 19:38 +0100
                                                          Re: Dropping C jameskuyper@verizon.net - 2018-03-22 12:19 -0700
                                                          Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 20:23 +0000
                                                          Re: Dropping C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-23 06:10 -0700
                                                          Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 14:54 +0100
                                                            Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-23 16:55 +0100
                                                              Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 17:46 +0100
                                                        Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:50 +0100
                                                        Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:54 +0100
                                            Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-22 16:43 +0000
                                              Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-22 10:39 -0700
                                            Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-22 11:47 -0500
                                            Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-24 00:59 -0700
                  Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:07 +0000
                    Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:37 +0000
                      Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:16 +0000
                        Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 20:30 +0000
                          Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:24 +0000
                            Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 23:06 +0000
                            Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-20 14:04 +0000
                        Re: Dropping C supercat@casperkitty.com - 2018-03-19 15:32 -0700
                          Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-19 19:03 -0500
                            Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:13 +0000
                              Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:25 +0100
                          Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 18:36 +0100
                        Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:33 +0100
                          Re: Dropping C supercat@casperkitty.com - 2018-03-19 16:34 -0700
                        Re: Dropping C asetofsymbols@gmail.com - 2018-03-20 00:58 -0700
                          Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-20 01:10 -0700
              Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-19 14:25 +1300
    Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:19 +0000

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

#128004

bartc <bc@freeuk.com> writes:

>BTW I've been meaning to ask this for a while: given an ordinary text 
>editor, and given the name of a function, how do you find that function 
>definition in a source file? I mean, going straight there rather then 
>scanning a hundred other occurrences of the name before you get to the 
>definition.

With vim, you have the choice of  ctags or cscope databases
to allow direct access to the definition (e.g. with cscope or ctags, <CTRL>-}
over an identifier will
go directly to the definition, even if it is in a different source file.
<CTRL>-T will return to the prior file/line.   The tag stack can be arbitrarily
deep.

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

#128010

On 19/03/2018 15:36, Scott Lurndal wrote:
> bartc <bc@freeuk.com> writes:
> 
>> BTW I've been meaning to ask this for a while: given an ordinary text
>> editor, and given the name of a function, how do you find that function
>> definition in a source file? I mean, going straight there rather then
>> scanning a hundred other occurrences of the name before you get to the
>> definition.
> 
> With vim, you have the choice of  ctags or cscope databases
> to allow direct access to the definition (e.g. with cscope or ctags, <CTRL>-}
> over an identifier will
> go directly to the definition, even if it is in a different source file.
> <CTRL>-T will return to the prior file/line.   The tag stack can be arbitrarily
> deep.
> 

That'll work from a general editor? Like Notepad?

When I was debugging some C recently, I created this macro:

  #define function

And, by linearly going through the file, 'function ' was added at the 
start of every function. That meant that, with my editor, I could very 
rapidly whizz forwards and backwards through the functions.

But I still couldn't find the definition of 'fred', since there would be 
an arbitrary type specification between 'function' and 'fred'.

And an arbitrary number of attributes, or macros expanding to attributes.

And conceivably, but fortunately rare,  any number of parentheses around 
'fred'.

And, sometimes, a new line.

So a simplistic editor won't cut it. You need one that is basically a C 
compiler. Unless you stick that 'function' macro right in front of the 
function name, but then you're just adding to the ghastliness.

-- 
bartc

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

#128017

bartc <bc@freeuk.com> writes:

> On 19/03/2018 15:36, Scott Lurndal wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> BTW I've been meaning to ask this for a while: given an ordinary text
>>> editor, and given the name of a function, how do you find that function
>>> definition in a source file? I mean, going straight there rather then
>>> scanning a hundred other occurrences of the name before you get to the
>>> definition.
>>
>> With vim, you have the choice of  ctags or cscope databases
>> to allow direct access to the definition (e.g. with cscope or ctags, <CTRL>-}
>> over an identifier will
>> go directly to the definition, even if it is in a different source file.
>> <CTRL>-T will return to the prior file/line.  The tag stack can be
>> arbitrarily
>> deep.
>>
>
> That'll work from a general editor? Like Notepad?

Vim is, of course, a general editor.  If you meant to ask specifically
about Notepad, you should have said Notepad in the question.

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

#128020

On 19/03/2018 18:14, Joe Pfeiffer wrote:
> bartc <bc@freeuk.com> writes:
> 
>> On 19/03/2018 15:36, Scott Lurndal wrote:
>>> bartc <bc@freeuk.com> writes:
>>>
>>>> BTW I've been meaning to ask this for a while: given an ordinary text
>>>> editor, and given the name of a function, how do you find that function
>>>> definition in a source file? I mean, going straight there rather then
>>>> scanning a hundred other occurrences of the name before you get to the
>>>> definition.
>>>
>>> With vim, you have the choice of  ctags or cscope databases
>>> to allow direct access to the definition (e.g. with cscope or ctags, <CTRL>-}
>>> over an identifier will
>>> go directly to the definition, even if it is in a different source file.
>>> <CTRL>-T will return to the prior file/line.  The tag stack can be
>>> arbitrarily
>>> deep.
>>>
>>
>> That'll work from a general editor? Like Notepad?
> 
> Vim is, of course, a general editor.  If you meant to ask specifically
> about Notepad, you should have said Notepad in the question.

I obviously mean any editor that just edits text and knows nothing about 
ctags or cscopes or databases or identifiers.

(How would a function definition get into such a database anyway. You 
download a C project; does it come with such databases, or do you have 
to run some utilities first?)

What I'm getting at is that there is no simple syntax form that can help 
ANY editor to trivially find any specific function. Or to not find it, 
if it exists outside of this source file.

-- 
bartc

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

#128021

On 03/20/2018 08:15 AM, bartc wrote:
> On 19/03/2018 18:14, Joe Pfeiffer wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> On 19/03/2018 15:36, Scott Lurndal wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>>
>>>>> BTW I've been meaning to ask this for a while: given an ordinary text
>>>>> editor, and given the name of a function, how do you find that function
>>>>> definition in a source file? I mean, going straight there rather then
>>>>> scanning a hundred other occurrences of the name before you get to the
>>>>> definition.
>>>>
>>>> With vim, you have the choice of  ctags or cscope databases
>>>> to allow direct access to the definition (e.g. with cscope or ctags, <CTRL>-}
>>>> over an identifier will
>>>> go directly to the definition, even if it is in a different source file.
>>>> <CTRL>-T will return to the prior file/line.  The tag stack can be
>>>> arbitrarily
>>>> deep.
>>>>
>>>
>>> That'll work from a general editor? Like Notepad?
>>
>> Vim is, of course, a general editor.  If you meant to ask specifically
>> about Notepad, you should have said Notepad in the question.
> 
> I obviously mean any editor that just edits text and knows nothing about
> ctags or cscopes or databases or identifiers.
> 
> (How would a function definition get into such a database anyway. You
> download a C project; does it come with such databases, or do you have
> to run some utilities first?)
> 
> What I'm getting at is that there is no simple syntax form that can help
> ANY editor to trivially find any specific function. Or to not find it,
> if it exists outside of this source file.

ctags and vi are almost as old as C...

-- 
Ian.

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

#128031

On 19/03/2018 19:20, Ian Collins wrote:
> On 03/20/2018 08:15 AM, bartc wrote:
>> On 19/03/2018 18:14, Joe Pfeiffer wrote:
>>> bartc <bc@freeuk.com> writes:
>>>
>>>> On 19/03/2018 15:36, Scott Lurndal wrote:
>>>>> bartc <bc@freeuk.com> writes:
>>>>>
>>>>>> BTW I've been meaning to ask this for a while: given an ordinary text
>>>>>> editor, and given the name of a function, how do you find that 
>>>>>> function
>>>>>> definition in a source file? I mean, going straight there rather then
>>>>>> scanning a hundred other occurrences of the name before you get to 
>>>>>> the
>>>>>> definition.
>>>>>
>>>>> With vim, you have the choice of  ctags or cscope databases
>>>>> to allow direct access to the definition (e.g. with cscope or 
>>>>> ctags, <CTRL>-}
>>>>> over an identifier will
>>>>> go directly to the definition, even if it is in a different source 
>>>>> file.
>>>>> <CTRL>-T will return to the prior file/line.  The tag stack can be
>>>>> arbitrarily
>>>>> deep.
>>>>>
>>>>
>>>> That'll work from a general editor? Like Notepad?
>>>
>>> Vim is, of course, a general editor.  If you meant to ask specifically
>>> about Notepad, you should have said Notepad in the question.
>>
>> I obviously mean any editor that just edits text and knows nothing about
>> ctags or cscopes or databases or identifiers.
>>
>> (How would a function definition get into such a database anyway. You
>> download a C project; does it come with such databases, or do you have
>> to run some utilities first?)
>>
>> What I'm getting at is that there is no simple syntax form that can help
>> ANY editor to trivially find any specific function. Or to not find it,
>> if it exists outside of this source file.
> 
> ctags and vi are almost as old as C...


OK, that's what I thought. A general editor won't do it, not unless you 
rope in the services of a separate program (a complicated one by the 
sound of it) to do all the work, which also sounds like it has to 
thoroughly understand and half-compile C source code.

But an Editor plus Special Add-on doesn't equal General Purpose Editor.

It's just another illustration of how C source syntax isn't really fit 
for purpose, because of all these numerous add-on programs you have to 
use to be able to work with it.

OK, let's throw down a challenge: how short a program can you write in 
pure C, to take any C source file, and produce a list of the function 
definitions and what line numbers they are on.

You're not allowed to just use system("ctags"), as we're trying to 
establish exactly how big a job the design of the language makes this task.

To make it a bit easier, you don't need to bother with dealing with 
#includes, #ifs, macros (which can change the results if fully 
expanded), comments, and string constants (both of which can contain 
what look like definitions).

It that is still too hard, you can rope in the help of another language.

I can tell you I can do this for my language with the following C code. 
(And using a dynamic language, it's trivial.) This version lazily just 
prints the whole line (so 'extractname' is a misnomer).

-----------------------------------------------------------

#include <stdio.h>
#include <string.h>

char* extractname(char* line) {
     int length=strlen(line);
     char* prefixes[] = {
         "global proc ",
         "global function ",
         "proc ",
         "function "};
     int i,plen;

     for (i=0; i<4; ++i) {
         plen=strlen(prefixes[i]);
         if (plen<length && memcmp(prefixes[i],line,plen)==0) {
             return line;
         }
     }
     return NULL;
}

int main(void) {
     char linebuffer[16384];
     FILE* fh;
     char *fnname;
     int lineno=0;

     fh=fopen("/pcl/pc_handlers.m","r");
     if (fh) {
         while (fgets(linebuffer,sizeof(linebuffer),fh)) {
             ++lineno;
             fnname=extractname(linebuffer);
             if (fnname)
                 printf("%5d: %s",lineno,fnname);
         }
         fclose(fh);
     }

}


-- 
bartc

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

#128040

bartc <bc@freeuk.com> writes:

> OK, that's what I thought. A general editor won't do it, not unless
> you rope in the services of a separate program (a complicated one by
> the sound of it) to do all the work, which also sounds like it has to
> thoroughly understand and half-compile C source code.
>
> But an Editor plus Special Add-on doesn't equal General Purpose Editor.
>
> It's just another illustration of how C source syntax isn't really fit
> for purpose, because of all these numerous add-on programs you have to
> use to be able to work with it.

My preference is to look at the problem as a statement that a General
Purpose Editor isn't fit for the purpose of editing source code beyond
simple changes.

Are there other languages you consider to have this functionality of
which you're bemoaning C's lack? Which ones did you have in mind?

-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

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

#128043

On 19/03/2018 22:00, Lowell Gilbert wrote:
> bartc <bc@freeuk.com> writes:
> 
>> OK, that's what I thought. A general editor won't do it, not unless
>> you rope in the services of a separate program (a complicated one by
>> the sound of it) to do all the work, which also sounds like it has to
>> thoroughly understand and half-compile C source code.
>>
>> But an Editor plus Special Add-on doesn't equal General Purpose Editor.
>>
>> It's just another illustration of how C source syntax isn't really fit
>> for purpose, because of all these numerous add-on programs you have to
>> use to be able to work with it.
> 
> My preference is to look at the problem as a statement that a General
> Purpose Editor isn't fit for the purpose of editing source code beyond
> simple changes.
> 
> Are there other languages you consider to have this functionality of
> which you're bemoaning C's lack? Which ones did you have in mind?

One very useful 'feature' is to have a keyword to introduce a function.

Some newer languages which are derived from C seem to have reintroduced 
that.

While C can emulate that with an empty macro, that is just never done.

At the same time, C has the ability to make function definitions even 
harder to see, by having a busy syntax indistinguishable at a glance 
from a variable declaration; the injection of attributes; and the 
possibility to insert macros almost anywhere, some of which add to the 
definition's header while others will replace elements, so you don't 
even know if what you're looking is function declaration or not.

Plus sometimes you will see a definition but it turns out to be a 
forward declaration.

OK, to not beat about the bush, the way C does it is a mess.

I can't answer about other languages; a lot of them do seem to use 
function prefixes and most of them can't do the crazy stuff that C can 
to make things impossible.


-- 
bartc

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

#128065

AT Tuesday 20 March 2018 06:17, bartc wrote:

> On 19/03/2018 22:00, Lowell Gilbert wrote:
>> bartc <bc@freeuk.com> writes:
>> 
>>> OK, that's what I thought. A general editor won't do it, not unless
>>> you rope in the services of a separate program (a complicated one by
>>> the sound of it) to do all the work, which also sounds like it has to
>>> thoroughly understand and half-compile C source code.
>>>
>>> But an Editor plus Special Add-on doesn't equal General Purpose Editor.
>>>
>>> It's just another illustration of how C source syntax isn't really fit
>>> for purpose, because of all these numerous add-on programs you have to
>>> use to be able to work with it.
>> 
>> My preference is to look at the problem as a statement that a General
>> Purpose Editor isn't fit for the purpose of editing source code beyond
>> simple changes.
>> 
>> Are there other languages you consider to have this functionality of
>> which you're bemoaning C's lack? Which ones did you have in mind?
> 
> One very useful 'feature' is to have a keyword to introduce a function.
> 
> Some newer languages which are derived from C seem to have reintroduced
> that.
> 
> While C can emulate that with an empty macro, that is just never done.
> 
> At the same time, C has the ability to make function definitions even
> harder to see, by having a busy syntax indistinguishable at a glance
> from a variable declaration; the injection of attributes; and the
> possibility to insert macros almost anywhere, some of which add to the
> definition's header while others will replace elements, so you don't
> even know if what you're looking is function declaration or not.
> 
> Plus sometimes you will see a definition but it turns out to be a
> forward declaration.
> 
> OK, to not beat about the bush, the way C does it is a mess.
> 
> I can't answer about other languages; a lot of them do seem to use
> function prefixes and most of them can't do the crazy stuff that C can
> to make things impossible.

And if C had this useless keyword, you would complain that it is a lot of 
typing.

-- 
Reinhardt

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

#128132

Le 19/03/2018 à 23:17, bartc a écrit :
> At the same time, C has the ability to make function definitions even 
> harder to see, by having a busy syntax indistinguishable at a glance 
> from a variable declaration;

I published this algorithm in this group around 10 years ago:

1) Eliminate strings
2) Eliminate comments
3) Count braces
4) If at level zero you find a sequence of a right paren ')' followed by 
an opening brace '{', you have found the start of a function.

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

#128135

On Wed, 21 Mar 2018 07:54:46 +0100, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>Le 19/03/2018 à 23:17, bartc a écrit :
>> At the same time, C has the ability to make function definitions even 
>> harder to see, by having a busy syntax indistinguishable at a glance 
>> from a variable declaration;
>
>I published this algorithm in this group around 10 years ago:
>
>1) Eliminate strings
>2) Eliminate comments
>3) Count braces
>4) If at level zero you find a sequence of a right paren ')' followed by 
>an opening brace '{', you have found the start of a function.


That won't deal with cases where the parenthesis-brace pair is wholly
or partly generated by a macro.  That usually would be poor form, but
there are cases where significant parts of functions are generated by
macros, I could see that happening there.  But hopefully it would be
rare.

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

#128140

On 21/03/2018 09:10, Robert Wessel wrote:
> On Wed, 21 Mar 2018 07:54:46 +0100, jacobnavia
> <jacob@jacob.remcomp.fr> wrote:
> 
>> Le 19/03/2018 à 23:17, bartc a écrit :
>>> At the same time, C has the ability to make function definitions even
>>> harder to see, by having a busy syntax indistinguishable at a glance
>>> from a variable declaration;
>>
>> I published this algorithm in this group around 10 years ago:
>>
>> 1) Eliminate strings
>> 2) Eliminate comments
>> 3) Count braces
>> 4) If at level zero you find a sequence of a right paren ')' followed by
>> an opening brace '{', you have found the start of a function.
> 
> 
> That won't deal with cases where the parenthesis-brace pair is wholly
> or partly generated by a macro.  That usually would be poor form, but
> there are cases where significant parts of functions are generated by
> macros, I could see that happening there.  But hopefully it would be
> rare.
> 


You would preprocess first, which would also get rid of the comments.

(Which is actually a method I use, to cut out all the crap and work with 
that looks like more conventional code rather than have to constantly 
wonder what is or what isn't a macro.)

But it would be bizarre to have an algorithm just to establish where 
functions start and end. Surely a properly-designed language would make 
it blindly obvious?

(Conclusion: C's design must have just been thrown drunkenly together. 
Would it have killed anybody to have required a 'function' keyword?)

I've never known a language so be so dependent on tools and algoritms 
and databases and special editors just to be able to read it!

Would it have killed anyone to have required a 'function' prefix or any 
such keyword? (Like pretty much every other language.)

-- 
bartc

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

#128141

On 21/03/2018 11:08, bartc wrote:

> (Conclusion: C's design must have just been thrown drunkenly together. 
> Would it have killed anybody to have required a 'function' keyword?)

Please ignore this paragraph that should have been edited out. I don't 
want to suggest that C's designers were drunkards.)

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

#128146

On Wednesday, March 21, 2018 at 4:18:06 AM UTC-7, Bart wrote:
> On 21/03/2018 11:08, bartc wrote:
> 
> > (Conclusion: C's design must have just been thrown drunkenly together. 
> > Would it have killed anybody to have required a 'function' keyword?)
> 
> Please ignore this paragraph that should have been edited out. I don't 
> want to suggest that C's designers were drunkards.)



It's a spam message. kushal bhattacharya has already decided what he is going to say before he calls. What you say is ignored. What Vennie Bowden says is beside the point. This is what comes about when dangerously poor self esteem takes over kushal bhattacharya's mind. Usenet is a self-governing concordat based on virtue. 

--
Top 15 Ways kushal bhattacharya Trolls
http://www.5z8.info/killallimmigrants_t8w8io_asian-brides
Jonas Eklundh

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

#128143

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 19/03/2018 à 23:17, bartc a écrit :
>> At the same time, C has the ability to make function definitions even
>> harder to see, by having a busy syntax indistinguishable at a glance
>> from a variable declaration;
>
> I published this algorithm in this group around 10 years ago:
>
> 1) Eliminate strings
> 2) Eliminate comments
> 3) Count braces
> 4) If at level zero you find a sequence of a right paren ')' followed
> by an opening brace '{', you have found the start of a function.

You have to eliminate character literals as well (e.g. '{').  Even so,
neither of these will be found:

  int (f(int x)) { return x; }
  int g(x) int x; { return x; }

and this

 int *p = (int[]){0};

will result in a false positive.

In addition to the complication caused by macros (at the very least they
can mess up the brace count) you have things like this to contend with:
  
  int h(int x) { return x; %>
  int i(int x) ??< return x; }

The simplest way to deal with macros, alternate punctuators and
trigraphs is probably just to pre-process the source.  But then your
algorithm needs to know how the pre-processor tracks file inclusion
because functions defined in header files should probably not be found
by this algorithm.

-- 
Ben.

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

#128145

On 21/03/2018 12:13, Ben Bacarisse wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> 
>> Le 19/03/2018 à 23:17, bartc a écrit :
>>> At the same time, C has the ability to make function definitions even
>>> harder to see, by having a busy syntax indistinguishable at a glance
>>> from a variable declaration;
>>
>> I published this algorithm in this group around 10 years ago:
>>
>> 1) Eliminate strings
>> 2) Eliminate comments
>> 3) Count braces
>> 4) If at level zero you find a sequence of a right paren ')' followed
>> by an opening brace '{', you have found the start of a function.
> 
> You have to eliminate character literals as well (e.g. '{').  Even so,
> neither of these will be found:
> 
>    int (f(int x)) { return x; }

I can't see the problem here. You have ")" followed by "{", and this "{" 
is encountered at level 0 if keeping track of left/right braces (ie. +1 
for { and -1 for }).

-- 
bartc

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

#128154

bartc <bc@freeuk.com> writes:

> On 21/03/2018 12:13, Ben Bacarisse wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>>> Le 19/03/2018 à 23:17, bartc a écrit :
>>>> At the same time, C has the ability to make function definitions even
>>>> harder to see, by having a busy syntax indistinguishable at a glance
>>>> from a variable declaration;
>>>
>>> I published this algorithm in this group around 10 years ago:
>>>
>>> 1) Eliminate strings
>>> 2) Eliminate comments
>>> 3) Count braces
>>> 4) If at level zero you find a sequence of a right paren ')' followed
>>> by an opening brace '{', you have found the start of a function.
>>
>> You have to eliminate character literals as well (e.g. '{').  Even so,
>> neither of these will be found:
>>
>>    int (f(int x)) { return x; }
>
> I can't see the problem here. You have ")" followed by "{", and this
> "{" is encountered at level 0 if keeping track of left/right braces
> (ie. +1 for { and -1 for }).

Yes, you are right.  Thanks.  A program might have trouble finding the
function name, but the pattern is OK.

-- 
Ben.

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

#128168

Le 21/03/2018 à 13:13, Ben Bacarisse a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> 
>> Le 19/03/2018 à 23:17, bartc a écrit :
>>> At the same time, C has the ability to make function definitions even
>>> harder to see, by having a busy syntax indistinguishable at a glance
>>> from a variable declaration;
>>
>> I published this algorithm in this group around 10 years ago:
>>
>> 1) Eliminate strings
>> 2) Eliminate comments
>> 3) Count braces
>> 4) If at level zero you find a sequence of a right paren ')' followed
>> by an opening brace '{', you have found the start of a function.
> 
> You have to eliminate character literals as well (e.g. '{').  Even so,
> neither of these will be found:
> 
>    int (f(int x)) { return x; }

The parentheses level is not zero in the inner scope. It will be found 
since at the global level (parentheses level zero) there is a clear 'à' 
followed by '{'


>    int g(x) int x; { return x; }
> 

This is no longer supported since C89...

> and this
> 
>   int *p = (int[]){0};
>
> will result in a false positive.
> 

Normally that would be int *p=NULL;

> In addition to the complication caused by macros (at the very least they
> can mess up the brace count) you have things like this to contend with:
>    
>    int h(int x) { return x; %>
>    int i(int x) ??< return x; }
>

Trigraphs aren't supported.


> The simplest way to deal with macros, alternate punctuators and
> trigraphs is probably just to pre-process the source.  But then your
> algorithm needs to know how the pre-processor tracks file inclusion
> because functions defined in header files should probably not be found
> by this algorithm.
> 

The algorithm finds all functions in the compilation unit.

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

#128170

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 21/03/2018 à 13:13, Ben Bacarisse a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 19/03/2018 à 23:17, bartc a écrit :
>>>> At the same time, C has the ability to make function definitions even
>>>> harder to see, by having a busy syntax indistinguishable at a glance
>>>> from a variable declaration;
>>>
>>> I published this algorithm in this group around 10 years ago:
>>>
>>> 1) Eliminate strings
>>> 2) Eliminate comments
>>> 3) Count braces
>>> 4) If at level zero you find a sequence of a right paren ')' followed
>>> by an opening brace '{', you have found the start of a function.
>> 
>> You have to eliminate character literals as well (e.g. '{').  Even so,
>> neither of these will be found:
[snip]
>>    int g(x) int x; { return x; }
>> 
>
> This is no longer supported since C89...

You mean your tool doesn't support it.  As I'm sure you know, it's still
perfectly valid in C99 and C11.

>> and this
>> 
>>   int *p = (int[]){0};
>>
>> will result in a false positive.
>
> Normally that would be int *p=NULL;

No, it initializes p as a non-null pointer, pointing to an int object
with the value 0.

[...]

>> The simplest way to deal with macros, alternate punctuators and
>> trigraphs is probably just to pre-process the source.  But then your
>> algorithm needs to know how the pre-processor tracks file inclusion
>> because functions defined in header files should probably not be found
>> by this algorithm.
>
> The algorithm finds all functions in the compilation unit.

A tool meant to find function declarations doesn't necessarily have to
handle all valid C code.  If you use macros to mess around with the
language syntax, or even if you use old-style functoin definitions, you
can't necessarily expect such a tool to work.  It would be nice if it
worked with 100% reliability, but I don't think it's necessary.  Full
compliance is less important for auxiliary tools than for compilers.

(jacob, if you see this, please acknowledge.  I suspect you've
killfiled me, which of course you're free to do, but if so I'd like
to know about it.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#128173

On Wednesday, March 21, 2018 at 2:45:49 PM UTC-5, Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> > Le 21/03/2018 à 13:13, Ben Bacarisse a écrit :
> >>    int g(x) int x; { return x; }
> >
> > This is no longer supported since C89...
> 
> You mean your tool doesn't support it.  As I'm sure you know, it's still
> perfectly valid in C99 and C11.

That syntax can also handle things like:

    int useArray(double arr[*][*], int, int);
    int useArray(arr, x, y)
       int x,y;
       double arr[x][y];
    {
      ...
    }

while newer-style function definitions can't.

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

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

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

csiph-web