Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Dropping C Date: Wed, 21 Mar 2018 12:45:38 -0700 Organization: None to speak of Lines: 64 Message-ID: References: <2hjrC.38651$%a5.4397@fx21.am4> <20180319151705.b62a6689c1344c41f2bf73ad@gmail.com> <0OQrC.13909$qM7.8865@fx29.iad> <1bk1u8x78k.fsf@pfeifferfamily.net> <44po3zvi7h.fsf@be-well.ilk.org> <87vadptynn.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="8fef62c5babeabfae505a3b4aebc529d"; logging-data="22151"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/XPLSQPbu82z5p9qA/k/bJ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:8+1Gx21FhfStQ5IUBftOO/wAzIY= sha1:NqN6NepG1In+R2RRdGorH4u7pX8= Xref: csiph.com comp.lang.c:128170 jacobnavia writes: > Le 21/03/2018 à 13:13, Ben Bacarisse a écrit : >> jacobnavia 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 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"