String im Kompilat

Siegfried schrieb:
> Ist so etwas möglich?

scheinbar schon, sonst würdest du ihn ja finden. Aber ich üblicherweise 
ist er drin. Oder suchst du im Hexfile?

Z.B. wenn Du mit 16-Bit-Zeichen arbeitest.

Ob Dein oben angeführtes Beispiel überhaupt funktioniert weiß ich nicht, 
aber Du bist möglicherweise über die Füße von Billy Boy gestolpert.
Die Windows-Suchfunktion ignoriert einen ganzen Sack voll Erweiterungen, 
ich weiß es von .Pas her und durchsucht diese (Kommentarlos) überhaupt 
nicht.
Also geh' mal ruhig fremd und freunde Dich, mit einer anderen 
(Suchhilfe) an.

@Wegstaben Verbuchsler
So mit einer Prise nachdenken, was könnte es heißen, na, na?, naaa? 
Vielleicht Versionskennung? Jetzt wo es klar ist, weißt Du bestimmt die 
Lösung...

Ansonsten:
Ich habe die Datei mit einem Texteditor durchsucht. Dabei ist mir 
aufgefallen dass kein einziger in der Software vorkommender String zu 
sehen ist. Kann es sein dass die exe vom Compiler implizit gepackt wird? 
Es ist übrigens ein GCC Crosscompiler der Code für einen ARM9 µC Linux 
Kleinrechner erzeugt.

Grüße
Siegfried

Siegfried schrieb:
> Ich habe die Datei mit einem Texteditor durchsucht
Suchst du auch in der richtigen Datei?

Im Moment gebe ich den String nur einmal an fprint, sonst ist dieser 
unbenutzt. Ich suche nochmal mit dem Hexeditor...

Dann mach Dir eine Versionsanzeige auf der Kommandozeile wie unter Un*x 
üblich.
Also "meinprogramm /v" gibt dann "Version 1.02" aus.

Klaus Wachtler schrieb:
> Dadurch daß es eine globale Variable ist, kann der Compiler sie nicht
> wegoptimieren - er weiß ja nicht, ob sie nicht in anderen Modulen
> benötigt wird.
Da es aber der Linker weiß, macht er genau das; wird u.a. verwendet um 
nicht benutzte Bibliotheksfunktionen wegzuoptimieren. Dieses Feature 
muss man zwar nicht einschalten, aber dadurch verliert man eben die 
sonstige Wegoptimierung von unbenutzten Variablen. Beim GCC kann man 
stattdessen __attribute__((used)) an die Variable schreiben um ein 
Wegoptimieren dieser einen Variable komplett zu verhindern.

Joachim Drechsel schrieb:
> Er hatte das aber mit printf() ausgegeben, da sollte es vorhanden sein
> weil's angesprochen bzw. verwendet wird (s. erster Post).
Ja, mein Hinweis bezog sich auf Klaus Wachtler's Vorschlag, der kein 
printf() verwendet und einfach davon ausgeht, dass nichts wegoptimiert 
wird.

Ich glaube hier geht irgendetwas durcheinander.

Von Siegfried:
>in der kompilierten Binärdatei wieder finden
>Kann es sein dass die exe vom Compiler implizit gepackt
>Es ist übrigens ein GCC Crosscompiler der Code für einen ARM9 µC Linux

An anderer Stelle:
>Du kannst in der vom Compiler generierten Assembler-Datei
>Ich habe die Datei mit einem Texteditor durchsucht
>Ich suche nochmal mit dem Hexeditor
>Im *.hex wirst du den auch so nicht finden.

Mich würde mal interessieren ob hier über:
xxxx,
xxxx.o,
xxxx.exe (Sonderwunsch),
xxxx.asm,
xxxx.hex,
xxxx.obj oder
wie auch immer die Dinger heißen geredet wird?

Vielleicht lässt sich dann irgendein System aufstellen, zusammen mit 
einem kleinen Hinweis darauf, ob mit dem guten, alten ASCII, oder mit 
einem seiner 16-Bit Verwandten, gearbeitet wird.

Siegfried schrieb:
> Ich habe die Datei mit einem Texteditor durchsucht.

Und der kommt auch mit Binärdateien zurecht?

> Dabei ist mir aufgefallen dass kein einziger in der Software vorkommender
> String zu sehen ist. Kann es sein dass die exe vom Compiler implizit
> gepackt wird?

Was ist denn "die exe"? Um welches Dateiformat handelt es sich?

Siegfried schrieb:
> Es ist übrigens ein GCC Crosscompiler ....

Endianess?

MfG Klaus

Alex W. schrieb:
>> meinprogramm -v wäre etwas unixüblicher :-)
>
> ein / ist heute aber viel cooler! Vorallem seit dem es /dance oder /huhn
> gibt

trotzdem ist das -v bei vielen einfach im Blut wenn sie die Version 
eines Programms erfragen möchten. (Also bei allen, die ernsthaft 
arbeiten, also mit Unixartigen Systemen.)

Das /h oder /v kenne ich soweit nur aus der Windowswelt. Und die ist ja 
insbesondere für die Konsistenz und Mächtigkeit auf der Kommandozeile 
bekannt. ;)

Also, ich habe zuerst in der erzeugten Assemblerdatei nachgesehen, da 
finde ich die Strings, z.B.

-LC11:
  .ascii "###VERSIONTOKEN1.21***\000
  .align2

Vermutlich deutet das align schon darauf hin dass jedes zeichen in 2 
Bytes verpackt wird?

Wenn ich auch nur ein einziges Zeichen ändere (einen einzelnen 
Buchstaben inmitten eines Strings) flippt das diff Tool aus, da ist 
allesmögliche anders! Ist warscheinlich irgendwie gepackt...