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

Groups > comp.lang.java.programmer > #32957

Re: A hypothetical compiler extension

Show all headers | View raw

On 10/29/2015 08:24 AM, Martin Gregorie wrote:
> On Wed, 28 Oct 2015 20:09:09 -0400, Arne Vajhøj wrote:
>
>> On 10/28/2015 7:50 AM, Martin Gregorie wrote:
>>> On Tue, 27 Oct 2015 22:21:20 -0400, Arne Vajhøj wrote:
>>>> On 10/27/2015 5:24 PM, Stefan Ram wrote:
>>>>>      The following is hypothetical AFAIK, but wouldn't it be nice?
>>>>>
>>>>>      One calls
>>>>>
>>>>> javac -Xlint:null
>>>>>
>>>>>      and then
>>
>>>>>      Javac alread has path-value-analysis as it already can detect
>>>>>      when a path of execution of a method (think of nested ifs)
>>>>>      accesses a variable that has not been defined yet in this path.
>>>>
>>>> I don't think it would be appropriate for the compiler to complain
>>>> about something that very well may not be a problem due to something
>>>> being done in the calling code.
>>
>>> There is a similar tool, 'lint' for C and has been for a very long
>>> time, though  Its name is 'lint'. There is an enhanced version,
>>> 'splint', which has replaced lint on some Linux distros. It is separate
>>> from the compiler. The preferred approach is to run lint after the
>>> source has been clean compiled. ake a look at their manpages or visit
>>> http://splint.org/ to see what it can do.
>>>
>>> I don't see why you shouldn't write a similar program for Java if
>>> you're feeling keen, though much simpler programs are also useful and
>>> can be whipped up in no time by using awk or Perl. For instance, I have
>>> one, written in awk, that searches C source for insecure string
>>> functions, i.e. using the strcpy() function instead of strncpy(). Its
>>> useful for hardening older code.
>>
>> There are a ton of tools available for Java that check for potential
>> unsafe constructs and violations of coding convention.
>>
>> Not sure if any of them checks for what Stefan want though.
>>
> If Stefan feels like checking out Coco/R, writing such a  tool could be
> the perfect project.
>
> CoCo/R is a 'compiler generator'. You describe the language you need to
> parse and it generates source for a parser. You just add back-end code to
> the parser to do what you need (generate byte code, check for unsafe
> constructs, etc). There is a Java version available which I used to parse
> C source in order to document preprocessor macros and function
> declarations (both K&R and ANSI). I found that to be fairly straight
> forward.
>
>    http://www.ssw.uni-linz.ac.at/Research/Projects/Coco/
>
>
The OpenJDK javac compiler itself is fairly easy to build, understand
and hack upon.

Lint.java
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/00a25f93cee8/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java>

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: A hypothetical compiler extension Arne Vajhøj <arne@vajhoej.dk> - 2015-10-27 22:21 -0400
  Re: A hypothetical compiler extension Martin Gregorie <martin@address-in-sig.invalid> - 2015-10-28 11:50 +0000
    Re: A hypothetical compiler extension Arne Vajhøj <arne@vajhoej.dk> - 2015-10-28 20:09 -0400
      Re: A hypothetical compiler extension Martin Gregorie <martin@address-in-sig.invalid> - 2015-10-29 12:24 +0000
        Re: A hypothetical compiler extension Jeff Higgins <jeff@invalid.invalid> - 2015-10-29 18:36 -0400

csiph-web