http://www.electronic-supply.dk/article/view.html?id=52974

Stor er jo ikke det samme som god til prototyper…

Deres styklistehåndtering er udemærket, og tvivlsspørgsmål håndteres hurtigt og effektivt.

De er hurtige og fleksible, når der skal fremstilles prototyperul på kort varsel, og er generelt meget proaktive, ved håndtering af komponentdisponering,

Kvalitetsmæssigt har vi gode erfaringer – det er ikke mange fejl vi ser på prototyperne.

Rådgivning og sparring er vi meget tilfredse med. Vi oplever både stor erfaring og kreativitet i de forslag de har til forbedringer på produktionsegnethed og produktmodning.

Før man bruger assert() skal man have #include med i sit program. Hvis man også har #define NDEBUG *før* #include (eller f.x. -DNDEBUG i Makefile) så oversættes hele assert()-linien til at ikke generere nogen kode. I en debug-version af programmet vil det altså køre fint, men når man slår debug fra for at sende en release ud mangler den så (mindst) et malloc()-opkald. Er man heldig vil man få advarsel fra sin compiler når man så bruger NewDataContainter, fordi den ikke er blevet assignet et værdi – men måske var den allerede det tidligere i programmet, da er der ikke nogen advarsel.

En regel for at undgå dette problem er at aldrig have kode med en side-effect inden i assert(). Den kode her burde altså skrives sådan her i stedet for:

NewDataContainter = (DataContainter *) malloc(sizeof (DataContainter));
assert(NewDataContainter);

Der kan muligvis også være nogle andre fejl, men det er svært at afgøre uden tilgang til mere kode fra det aktuelle scope. Jeg prøver alligevel at foreslå nogle ting som også kunne undersøges lidt mere indgående:

1. DataContainter burde nok hedde DataContainer. (uden t)

2. assert() ved malloc()-fejl er i min mening ikke god stil. Det gør at programmet umiddelbart afbrydes hvis en allokering ikke lykkes. Jeg mener at det tilstand burde håndteres bedre af programmet, før evt. afslut, selv om det kun er at give besked om *hvorfor* malloc() ikke lykkedes.

3. Det fremgår ikke hvad for type DataContainter er, hvilket kan påvirke sizeof() på flere måder. Med udgangspunkt i følgende har vi måske et problem:

struct dc {
unsigned char size;
unsigned char buffer[0];
};
typedef struct dc DataContainter;

En array med 0 elementer er valid C99 og en måde at sige til compilern “jeg ved ikke lige hvor stor den her kommer til at være ved runtime” – den buffer skal blive dynamisk allokeret til den rigtige størrelse senere i programmet. Sådan en array er altid nødt til at komme sidst i en struct, lige fordi det ikke går at vide hvor stor den skal være; altså hvorhen en efterfølgende medlem i structen kan gemmes. sizeof() på sådan en struct udelukker buffer fra størrelsesberegningen af samme grund. Hvis vi regner med at den her struct er byte aligned vil sizeof(DataContainter) altså være 1, og NewDataContainter->buffer vil være nødt til at allokeres separat.

4. Hvis DataContainter er en pointer til en array, i stedet som i 3. en typedef til en struct, vil sizeof(DataContainter) igen være 1, uanset hvor stor den udpegede array faktisk er.

1.-4. er kun potentielle fejl. Fejlen som opstår med #define NDEBUG før assert.h i programmet, eller -DNDEBUG (/DNDEBUG i Windows) ved build, er konkret og rigtig alvorlig.

Super service og kvalitet i forbindelse med prototype produktion.

Stor fleksibilitet, hurtig levering, god sparring og god kvalitet i printene.
Alt det man som udviklingshus ønsker sig.

assert( (NewDataContainter = (DataContainter *) malloc(sizeof (DataContainter))) );