[C] Statement has no effect

[Black-Xjuh]

Sinds dat ik van Eclipse Galileo naar Juno ben gegaan loop ik tegen een probleem aan.

Het begint met het aanroepen van een macro welke weer een andere functie aanroept:

code:

stap 1:
return (MODEM_CMD("test",1000) == MOD_RESP_OK);

stap 2:
#define MODEM_CMD(str,delay)    modem_cmd(PSTR(str),delay)

stap 3:
MODEM_RESP modem_cmd(const char * cmd, uint16 delay) {
    printm("AT");
    printm_np(cmd);
    printm("\r");

    return (modem_rec_resp(delay));
}

Het heeft altijd gewerkt en werkt ook nog steeds. Alleen krijg ik sinds de update naar Juno de melding "Statement has no effect" bij stap 1.

De code heb ik nu zo gemaakt dat de macro er tussen uit is:

code:

stap 1:
return (modem_cmd(PSTR("test"),1000) == MOD_RESP_OK);

stap 2:
MODEM_RESP modem_cmd(const char * cmd, uint16 delay) {
    printm("AT");
    printm_np(cmd);
    printm("\r");

    return (modem_rec_resp(delay));
}

Dit werkt net zo goed, alleen nu krijg ik dus de melding op PSTR("test"), "Statement has no effect". In eerste instantie dacht ik dat het probleem iets was met de return type maar het lijkt hem aan PSTR() te liggen.

Heeft iemand enig idee waarom het werkte en nog steeds werkt maar in Juno warnings oplevert en in Galileo niet?

[EddoH]

Wat doet de macro(?) PSTR en hoe is die gedefinieerd?

[Black-Xjuh]

PSTR is een standaard macro van AVR uit <avr/pgmspace.h> (deze is geinclude).

code:

/* Although in C, we can get away with just using __c, it does not work in
   C++. We need to use &__c[0] to avoid the compiler puking. Dave Hylands
   explaned it thusly,

     Let's suppose that we use PSTR("Test"). In this case, the type returned
     by __c is a prog_char[5] and not a prog_char *. While these are
     compatible, they aren't the same thing (especially in C++). The type
     returned by &__c[0] is a prog_char *, which explains why it works
     fine. */

# define PSTR(s) (__extension__({static char __c[] PROGMEM = (s); &__c[0];}))

[Soultaker]

Welke compiler gebruikt "Eclipse Juno"? Die macro-definitie gebruikt een GCC statement expression maar dat is een niet-standaard extensie die misschien niet door alle compilers goed geïnterpreteerd wordt.

In dit geval gewoon zou ik die hele PSTR macro achterwege laten omdat het onderscheid tussen een character-pointer en een character-array hier irrelevant is. Ik snap sowieso niet waarom die macro niet gewoon gedefinieerd is als:

C:

#define PSTR(s) ((const char*)(s))

...want dat lijkt me een net zo betrouwbare (en meer portable) manier om te garanderen dat s een pointer is.

Er is natuurlijk wel een groot verschil met de huidige macro: die garandeert dat de buffer writable is edit: maar dit wordt door PROGMEM waarschijnlijk weer ongedaan gemaakt.

edit:
Trouwens, volgens die GCC pagina:

In G++, the result value of a statement expression undergoes array and function pointer decay, and is returned by value to the enclosing expression.

Dus werkt (in tegenstelling tot wat het commentaar bij PSTR stelt) __c in plaats van __c[0] als expressie wél. Sterker nog, simpelweg:

C:

#define PSTR(s) (__extension__({(s);}))

...volstaat al om te garanderen dat de pointer naar een array omgezet wordt.

[ Voor 28% gewijzigd door Soultaker op 24-07-2012 13:58 ]

[Black-Xjuh]

Ik heb het geprobeerd en dit werkt niet in tegenstelling tot de macro die tot warnings leidt. Morgen ga ik het verder uitzoeken.

Beide maken ze gebruik van de AVR-GCC Toolchain en de AVR GNU Make Builder.

Als ik meer weet zal ik het posten.

[Soultaker]

Ik weet niet wat die printm() en printm_np() functies moeten doen, maar het kan zijn dat die laatste een string in program memory verwacht. In dat geval zou printm() in deze context wel werken.

Overigens wordt hier PSTR() wel gewoon met een cast geïmplementeerd zoals ik al suggereerde; nieuwere of oudere versie van die header?

[ Voor 77% gewijzigd door Soultaker op 24-07-2012 22:07 ]

[Wolf87]

Een hele leuke hoofdbreker waar ik ook tegenaan liep.
Sinds Indigo heeft Eclipse ingebouwde code analyse. Soort van linting, alleen dan heel summier.

Daar komt deze message vandaan, maar heeft biedt geen invloed op je programma of het bouwen ervan.

Als je het preferences scherm opent een zoekt op 'code analyse' kan je deze optie uitzetten.

[Black-Xjuh]

code:

#define printm(str,arg...) do{ CRIT_IN; if(!filelock_modem) { filelock_modem=true; CRIT_OUT; fprintf_P(&file_modem,PSTR(str),##arg); filelock_modem=false; } CRIT_OUT; }while(0)

#define printm_np(str,arg...) do{ CRIT_IN; if(!filelock_modem) { filelock_modem=true; CRIT_OUT; fprintf_P(&file_modem,str,##arg); filelock_modem=false; } CRIT_OUT; }while(0)

Het verschil zit er dus in of hij een pointer verwacht of deze zelf maakt met PSTR(str).

[Black-Xjuh]

Die ander gebruiken gaat dus niet, dan gaat hij een pointer proberen te casten naar een pointer?

Het blijft raar, op een of andere manier werken je andere twee methodes beide niet net zoals de macro uit de laatste link ook niet werkt. Het probleem is dat er dan geen AT(str)\r naar het modem wordt verzonden maar AT(heleboel willekeurige karakters)\r.

De pointer verwijst dus niet naar de juiste plek in tegenstelling tot de manier waarop de warnings worden veroorzaakt.

Als ik bij Code Analysis de "Statement has no effect" uitzet blijven de meldingen alsnog komen, dat werkt dus ook niet helemaal zoals het hoort. En sowieso is dit dan geen oplossing voor dit specifieke probleem en zie ik ook geen warning als die er wel echt is.

[farlane]

Ik vermoed toch echt dat je code geheugen probeert te benaderen met functies die alleen met RAM adressen werken of andersom.

Iig zal het uitschakelen van warnings niet snel een probleem in de code oplossen.