mboost-dp1
Rust ooops
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
#3
Jeg ser ikke noget problem i det. Hvis du allerede er på et stadie hvor du skal kompilere noget kode, så bør du stole på alt koden og hele din build chain.
Jeg er temmelig sikker på at du kunne gøre noget lign. med en makefile, og jeg ved at Xcode / Visual Studio / Node projekter også kan køre commands på compile time.
Jeg ser ikke noget problem i det. Hvis du allerede er på et stadie hvor du skal kompilere noget kode, så bør du stole på alt koden og hele din build chain.
Jeg er temmelig sikker på at du kunne gøre noget lign. med en makefile, og jeg ved at Xcode / Visual Studio / Node projekter også kan køre commands på compile time.
#4
Stort set alle build systemer har en mulighed for at udføre eksterne kommandoer. Men det er ikke så overraskende. Build konfigurationer reelt et build script og at script kan udføre noget er helt naturligt.
Men her er det specielle ved rust proc_macro er at det ligger i selve source code og compileren.
Jeg kan ikke umiddelbart komme i tanke om noget tilsvarende. Tætteste er javac annotation processor. Men der skal man trods alt gøre noget eksplicit for at aktivere.
Du har nok ret i at den praktisk betydning ikke er stor. Hvis man ikke stoler nok på source code til at turde compile den med den her features eksistens, så turde man ikke køre det genererede program uden den her features eksistens.
Men en noget speciel feature.
Og jeg vil ikke blive overrasket hvis ondsindede personer finder en praktisk anvendelse i.f.m. angreb på build servere.
Stort set alle build systemer har en mulighed for at udføre eksterne kommandoer. Men det er ikke så overraskende. Build konfigurationer reelt et build script og at script kan udføre noget er helt naturligt.
Men her er det specielle ved rust proc_macro er at det ligger i selve source code og compileren.
Jeg kan ikke umiddelbart komme i tanke om noget tilsvarende. Tætteste er javac annotation processor. Men der skal man trods alt gøre noget eksplicit for at aktivere.
Du har nok ret i at den praktisk betydning ikke er stor. Hvis man ikke stoler nok på source code til at turde compile den med den her features eksistens, så turde man ikke køre det genererede program uden den her features eksistens.
Men en noget speciel feature.
Og jeg vil ikke blive overrasket hvis ondsindede personer finder en praktisk anvendelse i.f.m. angreb på build servere.
arne_v (5) skrev:
Jeg kan ikke umiddelbart komme i tanke om noget tilsvarende. Tætteste er javac annotation processor. Men der skal man trods alt gøre noget eksplicit for at aktivere.
FORKERT. javac er lige så slem.
Her kommer demo.
Først den helt normale library funktionalitet.
C:\Work\jap>cd malwarelib
C:\Work\jap\malwarelib>cd mylib
C:\Work\jap\malwarelib\mylib>type BrilliantStuff.java
package mylib;
public class BrilliantStuff {
public void demo() {
System.out.println("BrilliantStuff.demo called");
}
}
C:\Work\jap\malwarelib\mylib>javac BrilliantStuff.java
C:\Work\jap\malwarelib\mylib>cd ..
C:\Work\jap\malwarelib>jar cvf ..\brilliant.jar mylib\*.class
added manifest
adding: mylib/BrilliantStuff.class(in = 429) (out= 291)(deflated 32%)
C:\Work\jap\malwarelib>cd ..
C:\Work\jap>type Test.java
import mylib.BrilliantStuff;
public class Test {
public static void main(String[] args) {
BrilliantStuff bs = new BrilliantStuff();
bs.demo();
}
}
C:\Work\jap>javac -cp brilliant.jar Test.java
C:\Work\jap>java -cp .;brilliant.jar Test
BrilliantStuff.demo called
Det er helt normalt.
Og så annotation processor som jeg huskede den.
C:\Work\jap>cd malwarelib
C:\Work\jap\malwarelib>cd myproc
C:\Work\jap\malwarelib\myproc>type Malware.java
package myproc;
import java.util.HashSet;
import java.util.Set;
import javax.annotation.processing.AbstractProcessor;
import javax.annotation.processing.ProcessingEnvironment;
import javax.annotation.processing.RoundEnvironment;
import javax.lang.model.SourceVersion;
import javax.lang.model.element.TypeElement;
public class Malware extends AbstractProcessor {
@Override
public synchronized void init(ProcessingEnvironment env) {
System.out.println("Wiping harddrive");
}
@Override
public boolean process(Set<? extends TypeElement> annoations, RoundEnvironment env) {
return false;
}
@Override
public Set<String> getSupportedAnnotationTypes() {
return new HashSet<String>();
}
@Override
public SourceVersion getSupportedSourceVersion() {
return SourceVersion.latestSupported();
}
}
C:\Work\jap\malwarelib\myproc>javac Malware.java
C:\Work\jap\malwarelib\myproc>cd ..
C:\Work\jap\malwarelib>jar uvf ..\brilliant.jar myproc\*.class
adding: myproc/Malware.class(in = 1080) (out= 552)(deflated 48%)
C:\Work\jap\malwarelib>cd ..
C:\Work\jap>javac -cp brilliant.jar Test.java
C:\Work\jap>java -cp .;brilliant.jar Test
BrilliantStuff.demo called
C:\Work\jap>javac -cp brilliant.jar -processorpath brilliant.jar -processor myproc.Malware Test.java
Wiping harddrive
C:\Work\jap>java -cp .;brilliant.jar Test
BrilliantStuff.demo called
Ingen brok fra mig - hvis man eksplicit beder javac om at køre en annotation processor i kommando linien, så er det ikke overraskende at den gør det.
Men man har valgt også at supportere Java service model.
C:\Work\jap>cd malwarelib
C:\Work\jap\malwarelib>type META-INF\services\javax.annotation.processing.Processor
myproc.Malware
C:\Work\jap\malwarelib>jar uvf ..\brilliant.jar META-INF\services\*
adding: META-INF/services/javax.annotation.processing.Processor(in = 16) (out= 18)(deflated -12%)
C:\Work\jap\malwarelib>cd ..
C:\Work\jap>javac -cp brilliant.jar Test.java
Wiping harddrive
C:\Work\jap>java -cp .;brilliant.jar Test
BrilliantStuff.demo called
Yuck!
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.