Dotaz: C/C++: gcc mi zahazuje symbol

[kralyk z abclinuxu]

Ahoj,
Mám zdroják v tomhle znění:

static const unsigned char data[] =
{
  0x5e, 0x7, //atd, atd,...
}

což jsou nějaká data, která potřebuju.
Když to ale zkompiluju v gcc nebo v g++ s kteroukoli z -Ox úrovní větší než nula, výsledný .o je prakticky prázdný, rozhodně neobsahuje data. Když odendám const, vše je ok. Já bych ale radši, aby tam const byl...

Jak to vyřešit? Nejradši bych úpravnou zdrojáku. Možná to je něco banálního, ale já na to nemůžu přijít...
Díky za každou radu.

---

---

Odpovědi

[Jirka P]

Nic se neděje...

static znamená, že tahle data jsou viditelná jen z daného modulu (tzn. ne z jiných .o). gcc jenom usoudí, že ta data nejsou v daném modulu čtena (když je prázdný), a tak je zahodí.

Proč chceš, aby tam data byla?

[kralyk z abclinuxu]

Když static odendám, chová se to úplně stejně... Taky jsem to tam původně neměl...

No ale já už na to přišel.
Když před to dám extern, nezmizí to.
Takže to vypadá takhle:

extern const unsigned char data[];
const unsigned char data[] =
{
  0x5e,0x7, //atd...
}

Takhle to nvyhodí ani při -Os...

[Sinuhet]

U promennych je static default, takze jeho explicitnim pridanim ci odstranenim na vyznamu deklarace nic nezmenite.

[kralyk z abclinuxu]

Od, dík za info. Ono vzhledem k tomu, že to pole je v global scope, tak ani auto být nemůže. Čili lepší řešení než to s tím extern asi nebude, nebo jo?

[Michal Kubeček]

Možná by pomohlo, kdybyste naznačil, k čemu tam ta data vlastně jsou, když je v programu nepoužijete. To má být nějaká značka, kterou pak ve spustitelném souboru někdo hledá?

[kralyk z abclinuxu]

Já je v programu použiju, samozřejmě. Ale na úplně jiném místě v jiném objektu (zase přes extern) a gcc to zřejmě nepozná...
Ono totiž tenhle zdroják je generovaný v průběhu kompilace... Ano já vím, jsem úchyl

[Michal Kubeček]

V tom případě to samozřejmě nesmí být static, static je právě to, co se nikde mimo daný modul nepoužije. Klíčové slovo static se používá právě tam, kde víte, že danou funkci nikde jinde použít nechcete, a chcete se vyhnout potenciální kolizi se stejnojmennými (opět static) symboly v jiných modulech.

[kralyk z abclinuxu]

Ne ne, zřejmě úplně přesně nerozumíte tomu static.
static znamená, že ta proměná je staticky alokovaná. auto znamená, že proměnná je automaticky alokovaná podle toho, kdy kontext vejde v platnost.
Z toho logicky plyne, že globální proměnná nemůže být auto (a pochopitelně ani register, což je specielní případ auto).

Když potřebuju static proměnnou z nějakého modulu vidět v jiném, použiju na to právě extern, který značí, že pamět pro daný identifikátor se vůbec nealokuje, vůbec neřeší, protože je řešena jinde.

Vzhledem k tomu, že jiné možnosti než static, auto, register a extern nejsou, tak to moje pole musí být static, a je to tak i správně.

[Michal Kubeček]

Ne ne, zřejmě úplně přesně nerozumíte tomu static.

Myslíte? Tak se podívejme do normy:

1. An identifier declared in different scopes or in the same scope more than once can be made to refer to the same object or function by a process called linkage.²¹⁾ There are three kinds of linkage: external, internal, and none.

2. In the set of translation units and libraries that constitutes an entire program, each declaration of a particular identifier with external linkage denotes the same object or function. Within one translation unit, each declaration of an identifier with internal linkage denotes the same object or function. Each declaration of an identifier with no linkage denotes a unique entity.

3. If the declaration of a file scope identifier for an object or a function contains the storage class specifier static, the identifier has internal linkage.²²⁾

[Vojtěch Horký]

Když potřebuju static proměnnou z nějakého modulu vidět v jiném, použiju na to právě extern, který značí, že pamět pro daný identifikátor se vůbec nealokuje, vůbec neřeší, protože je řešena jinde.

Máte nějaký příklad? Jakmile proměnnou označím jako extern, je to pouze její deklarace a překladač ví, že adresu doplní až linker (protože definice je někde jinde). V okamžiku, kdy proměnnou označím jako static, překladač ji zpřístupní pouze v daném modulu.

A rozhodně nedovolí, aby proměnnou v hlavičkovém souboru označenou jako extern někdo označil jako static v .c souboru.

Nebo tenhle příklad je o něčem jiném, než co jste myslel?

==> data.h <==
#ifndef _DATA_GUARD
#define _DATA_GUARD

extern const int data[];

#endif

==> data.c <==
#include "data.h"

const int data[] = { 0, 2, 5 };


==> main.c <==
#include <stdio.h>
#include "data.h"

int main() {
	printf("data[0] = %d\n", data[0]);
	return 0;
}



==> Makefile <==
CC = gcc
CLFAGS = -Wall

static: data.o main.o
	$(CC) $(CFLAGS) -o $@ data.o main.o

%.o: %.c data.h
	$(CC) $(CFLAGS) -c -o $@ $< 

[kralyk z abclinuxu]

V tomhle případě můžete klidně v data.c proměnnou data[] deklarovat jako static a nic se nestane. Jestli mi nevěříte, zkuste si to.

Hint: Ona už static by-default je, i když to tam není napsaný

[Vojtěch Horký]

Jestli mi nevěříte, zkuste si to.

Já jsem si to právě zkoušel .

$ cat data.c 
#include "data.h"

static const int data[] = { 0, 2, 5 };

$ make
gcc  -c -o data.o data.c 
data.c:3:18: error: static declaration of ‘data’ follows non-static declaration
data.h:4:18: note: previous declaration of ‘data’ was here
make: *** [data.o] Error 1

[kralyk z abclinuxu]

Ok dobře, mea culpa. Mně to předtím "fungovalo", asi jsem někde něco zapomněl...

[Vojtěch Horký]

Čili lepší řešení než to s tím extern asi nebude, nebo jo?

S tím extern je to IMHO správné (ne lepší) řešení. Pokud má být nějaké proměnná dostupná v jiném modulu (*.o souboru), tak by tohle mělo fungovat:

data.h:
extern const unsigned char data[];

data.c:
// tady IMHO extern být nemá, protože tohle je 
// právě ta jejich definice
const unsigned char data[] = { ... }; 

soubor_co_data_pouziva.c:
#include "data.h"

...
printf("data[0] = %d\n", (int) data[0]);

A dokud nebudou ty data nikdy použita, tak je asi stejně vyhodí linker.

[kralyk z abclinuxu]

Jo, tohle jsem to zkoušel... Ono je to taky logické řešení.
Ale vyhazoval to už při kompilaci. Mám podezření, že to je tím, že u toho data.h on nezná velikost toho pole, kdežto v tom data.c je vlastně přesná velikost, tím že tam je initializator, čili on si ty dva možná nemusí spojit (jen hádám)...

[petris_]

A nezapomnel jste data.h do toho data.c naincludovat?

[kralyk z abclinuxu]

No, to ani nejde, protože ten data.c je generovaný compile-time.
V opačném případě by to asi problém řešilo, to máš pravdu...

[Vojtěch Horký]

No, to ani nejde, protože ten data.c je generovaný compile-time.

To by snad nemělo vadit, ne? Dokud to vypadá nějak takhle:

data.o: data.c
    $(CC) -o $@ $<

data.c: neco
    generuj.sh >$@

Tak by neměl být problém udělat něco jako (echo '#include "data.h"; generuj.sh ) >$@.

[kralyk z abclinuxu]

Používám CMake. Ale já to nemusím řešit, už mi to funguje
Krom toho to moje řešení je naprosto ekvivalentní, protože to #include "data.h" by ve výsledku neudělalo nic jiného, než přidalo tu řádku, kterou jsem tam přidal ručně...

[Michal Kubeček]

Řešení s includem má jednu zásadní výhodu: neriskujete, že jednoho dne tu deklaraci na jednom z těch dvou míst změníte a zapomenete, že ji máte ještě někde jinde.