[C C++]Dipendenze eseguibile che variano in base ad un'istruzione e l'atoi maledetta

[Donbabbeo]

Mi sto occupando del refactoring di un vecchissimo progetto legacy ed in questi giorni sto verificando le dipendenze che si porta dietro.

Armato di DependencyWalker e di uno degli innumerevoli eseguibili che compongono il progetto (uno stramaledetto gestionale scritto in un linguaggio C misto C++, pieno di incongruenze, multiple istruzioni sulla stessa riga, zero commenti, la peggior convenzione per i nomi mai concepita ed indentazioni completamente casuali), salta fuori che all'incirca dal 2009 in avanti è così:

Non sarebbe un grosso problema se non fosse per il fatto che prima del 2009 la situazione era questa:

E con mia immensa gioia devo accollarmi il compito di tornare alla vecchia situazione mantenendo però le modifiche fatte al codice nel frattempo.
Mi sono sorbito tutto il codice e confrontandolo con la vecchia versione file per file (non hanno mai usato alcuna forma di Version Control, mannaggia loro) ed ho rintracciato il problema.

Si tratta di una funzione in una libreria del progetto che al netto di tutta la fuffa inutile si può, con mio grande stupore, tradurre in:

chain(str, pps)
	char *pps;
    char *str;
{
    int pp = 0;

	pp = atoi(pps);
	
	// ic sunt leones.

In pratica l'errore è generato dall'atoi.
Ma ancora più incredibile è che se io commento il rigo o al posto dell'atoi metto l'assegnazione diretta di un valore numerico tipo 0, 1 o 3, la libreria che contiene tale funzione compila bene, ma l'eseguibile a cui viene linkata la .lib restituisce i seguenti errori in compilazione:

nafxcw.lib(wincore.obj) : error LNK2001: unresolved external symbol __imp__InitCommonControls@0
nafxcw.lib(wincore.obj) : error LNK2001: unresolved external symbol __imp__DragAcceptFiles@8
nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol _ClosePrinter@4
nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol _DocumentPropertiesA@24
nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol _OpenPrinterA@12
nafxcw.lib(filecore.obj) : error LNK2001: unresolved external symbol __imp__SHGetFileInfoA@20
nafxcw.lib(filecore.obj) : error LNK2001: unresolved external symbol _GetFileTitleA@12

Tutto ciò rasenta il ridicolo se al contrario assegno un valore come 2, 4 o qualsiasi altro numero: in tal caso la libreria compila bene, compila bene l'eseguibile e mi ritrovo esattamente con le sole 4 dipendenze che sto agognando.

Non so più a che santo appellarmi, qualcuno sa indirizzarmi verso una soluzione?

[sottovento]

Suggerimento 1: tieni duro! Ce la farai!
Suggerimento 2: rifiutati di credere ai fantasmi. Rifiutati di credere che sia l'atoi() a generare quel problema di link (anche perche' potresti riscriverla in 1 minuto, ma immagino che il problema di link resti).

Considera i due problemi separatamente. Anche se in apparenza sembrano correlati, fai finta che la correlazione non esista.

Capisco che per motivi di sintesi hai dovuto fare dei tagli ed il procedimento che hai seguito e' perfettamente logico.
Tuttavia quando succedono queste cose e' molto probabile che si sia perso qualcosa dietro strada, magari qualcosa a cui non hai dato peso.
Prova a pensare ad una seconda strada, perfettamente logica come la prima, che possa portarti ad isolare il problema, oppure fai il contrario: cerca di provocare il problema!


Domanda: hai parti di codice generato automaticamente? Ho avuto un problema simile con il codice di un cliente. Sono diventato matto prima di capire che c'erano dei fogli Excel che contenevano delle macro, e quelle macro generavano del codice a seconda dei valori inseriti nel foglio elettronico. Se queste cose non ti vengono dette, non le troverai mai!!

Buona fortuna

[Daniels118]

Non so se possa tornare utile, ma visto che ci siamo, puoi indicare quale compilatore/ide e sistema operativo stai utilizzando?
Gli errori che ricevi possono dipendere da 2 possibili cause:
1) nel processo di link non sono incluse le librerie che contengono tali funzioni;
2) nei sorgenti del tuo progetto non sono inclusi gli header relativi a tali librerie, o gli header inclusi sono relativi ad una versione diversa delle librerie effettivamente utilizzate in fase di link.
Prova a cercare gli errori su google, dovresti trovare sia le librerie che gli header da aggiungere.
Il fatto che mettendo un valore piuttosto che un altro il problema sparisca è abbastanza strano, le considerazioni di sottovento sono valide, comunque ti consiglierei di controllare il makefile cercando eventuali istruzioni che non siano compilazione/linking.

[Donbabbeo]

Originariamente inviato da sottovento

Suggerimento 1: tieni duro! Ce la farai!
Suggerimento 2: rifiutati di credere ai fantasmi. Rifiutati di credere che sia l'atoi() a generare quel problema di link (anche perche' potresti riscriverla in 1 minuto, ma immagino che il problema di link resti).

Grazie per l'incoraggiamento

Ovviamente sono consapevole che l'atoi non ha colpe, la prima cosa che ho fatto è stata creare una funzione ad hoc per rimpiazzarla (sia un atoi fatto in casa che una funzione stupida che ritorni direttamente un intero) e l'errore permane.

Originariamente inviato da Daniels118

Non so se possa tornare utile, ma visto che ci siamo, puoi indicare quale compilatore/ide e sistema operativo stai utilizzando?
Gli errori che ricevi possono dipendere da 2 possibili cause:
1) nel processo di link non sono incluse le librerie che contengono tali funzioni;
2) nei sorgenti del tuo progetto non sono inclusi gli header relativi a tali librerie, o gli header inclusi sono relativi ad una versione diversa delle librerie effettivamente utilizzate in fase di link.
Prova a cercare gli errori su google, dovresti trovare sia le librerie che gli header da aggiungere.
Il fatto che mettendo un valore piuttosto che un altro il problema sparisca è abbastanza strano, le considerazioni di sottovento sono valide, comunque ti consiglierei di controllare il makefile cercando eventuali istruzioni che non siano compilazione/linking.

Sto usando Visual Studio C++ 6.0 su Windows XP in macchina virtuale (purtroppo è un programma legacy e non gira su altre versioni di VC++ )

Capisco che la causa principale sembra essere un problema di linking, ciò che trovo assurdo è che basta commentare la chiamata alla funzione chain o cambiare l'istruzione con l'atoi per far compilare senza problemi...

Speriamo di riuscire a svelare l'arcano

[Daniels118]

Ah-ehm: vogliate perdonare la mia ignoranza, ma il seguente codice:

chain(str, pps)
	char *pps;
    char *str;
{

non ha qualcosa di ambiguo?
Premetto che non ho mai programmato in C sotto Visual Studio, però il codice sopra riportato mi sembra che si discosti parecchio dal C standard:
1) manca il tipo di dato restituito dalla funzione (sarà void? Ci vuole comunque);
2) le variabili locali sono state dichiarate prima dalla parentesi graffa?!

[van9]

Originariamente inviato da Daniels118

Ah-ehm: vogliate perdonare la mia ignoranza, ma il seguente codice:

chain(str, pps)
	char *pps;
    char *str;
{

non ha qualcosa di ambiguo?
Premetto che non ho mai programmato in C sotto Visual Studio, però il codice sopra riportato mi sembra che si discosti parecchio dal C standard:
1) manca il tipo di dato restituito dalla funzione (sarà void? Ci vuole comunque);
2) le variabili locali sono state dichiarate prima dalla parentesi graffa?!

E' C pre-ANSI. Di default si ritornava un int e quello era il modo corretto di dichiarare i parametri formali (fuori dal corpo della function).

[Donbabbeo]

Originariamente inviato da Daniels118

Ah-ehm: vogliate perdonare la mia ignoranza, ma il seguente codice:

chain(str, pps)
	char *pps;
    char *str;
{

non ha qualcosa di ambiguo?
Premetto che non ho mai programmato in C sotto Visual Studio, però il codice sopra riportato mi sembra che si discosti parecchio dal C standard:
1) manca il tipo di dato restituito dalla funzione (sarà void? Ci vuole comunque);
2) le variabili locali sono state dichiarate prima dalla parentesi graffa?!

Si tratta di un vecchissimo codice legacy che usa ancora la notazione old-style per le dichiarazioni dei parametri e non la notazione a prototipo diventata lo standard de facto.
Aggiungo inoltre che il progetto è praticamente privo di files di intestazione, ogni funzione aggiunta viene automaticamente riconosciuta in tutto il codice (buttando fuori decine di warning, sarà per questo che li tengono disattivati? )

Non parlarmene, non faccio che combattere con gli altri per far adottare uno stile di programmazione sano invece di sto schifo di boiate. Fortuna che il 90% del tempo programmo applicazioni standalone di contorno a questo minestrone di codice.

[vbextreme]

posta esattamente tutta la funzione incrimitata e la sua chiamata.
con tre righe e senza sfera di cristallo è impossibile aiutarti.

[Daniels118]

E forse è proprio questo l'errore. Quando il compilatore non trova una chiamata ad una funzione non definita (né prototipata) genera un warning e crea automaticamente un prototipo sulla base dei parametri utilizzati nella chiamata stessa. Tale prototipo potrebbe non essere accurato e quindi potrebbe non coincidere con la reale definizione della funzione, e pertanto in fase di link la funzione potrebbe non essere trovata: il nome effettivo della funzione infatti viene costruito concatenando al nome definito dall'utente la stringa "@n", dove n se non ricordo male è la lunghezza in byte dei parametri passati (da cui i messaggi es. __imp__DragAcceptFiles@8).

[marco.r]

Originariamente inviato da Daniels118

E forse è proprio questo l'errore. Quando il compilatore non trova una chiamata ad una funzione non definita (né prototipata) genera un warning e crea automaticamente un prototipo sulla base dei parametri utilizzati nella chiamata stessa. Tale prototipo potrebbe non essere accurato e quindi potrebbe non coincidere con la reale definizione della funzione, e pertanto in fase di link la funzione potrebbe non essere trovata: il nome effettivo della funzione infatti viene costruito concatenando al nome definito dall'utente la stringa "@n", dove n se non ricordo male è la lunghezza in byte dei parametri passati (da cui i messaggi es. __imp__DragAcceptFiles@8).

Sembra probabile anche a me.
Ipotesi di quel che succede

* le funzioni che non riesce a linkare sono state utilizzate senza includere le intestazioni della libreria di sistema.

* il compilatore usa una dichiarazione un po' diversa e si aspetta che tu gliele implementi

* aggiungendo atoi, per caso includi le librerie che ti servono e per culo vanno bene (puo' succedere se cambia solo il tipo di ritorno o non usi alcuni argomenti)

Il mio suggerimento e' di cercare dove vengono usate le funzioni che non vengono trovate e verificare se sono stati aggiunti gli include di sistema

[banryu79]

Iscritto!
Questo problema vince a mani basse il premio "code horror" del semestre

[Donbabbeo]

Originariamente inviato da banryu79

Iscritto!
Questo problema vince a mani basse il premio "code horror" del semestre

Per il momento mi sono arreso, è una vita che spingo per fare un refactoring come dio comanda ma qui si continua a mettere pezze su pezze... Mi stupisco che dopo 30 anni ancora funziona più o meno bene...

[Daniels118]

Originariamente inviato da Donbabbeo

Per il momento mi sono arreso, è una vita che spingo per fare un refactoring come dio comanda ma qui si continua a mettere pezze su pezze... Mi stupisco che dopo 30 anni ancora funziona più o meno bene...

Ricorda, come dice "Lello": <<<chi parte sa da che cosa fugge, ma non sa che cosa cerca!>>