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

Groups > comp.lang.java.programmer > #32950 > unrolled thread

Re: A hypothetical compiler extension

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#32950 — Re: A hypothetical compiler extension

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
>
> void m( final java.lang.Object o )
> { java.lang.System.out.println
>    ( o.toString() ); }
>
>    gives
>
>    ( o.toString() ); }
>      ^
> Warning: o might be null.
>
>    . One rewrites to
>
> void m( final java.lang.Object o )
> { if( o != null )
>    java.lang.System.out.println
>    ( o.toString() ); }
>
>    and the warning disappears.
>
>    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.

Defensive coding is good, but it should be a developer
choice not something that the compiler get involved in.

The local variable not having gotten a value is a slightly
different case as it will either happen or the code has
been structured badly for the task.

Arne

[toc] | [next] | [standalone]

#32952

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
>>
>> void m( final java.lang.Object o )
>> { java.lang.System.out.println
>>    ( o.toString() ); }
>>
>>    gives
>>
>>    ( o.toString() ); }
>>      ^
>> Warning: o might be null.
>>
>>    . One rewrites to
>>
>> void m( final java.lang.Object o )
>> { if( o != null )
>>    java.lang.System.out.println ( o.toString() ); }
>>
>>    and the warning disappears.
>>
>>    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.
> 
> Defensive coding is good, but it should be a developer choice not
> something that the compiler get involved in.
> 
> The local variable not having gotten a value is a slightly different
> case as it will either happen or the code has been structured badly for
> the task.
> 

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.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#32954

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.

Arne

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

#32955

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/


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#32957

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>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web