goMatlab - Mein MATLAB Forum

Mein MATLAB Forum

  
Login  | Registrieren
Bücher:

Stochastische Signale: Übungen und einem MATLAB-Praktikum

Fachkräfte:
Testingenieur (w/m) Testframework für Simulink-basierte Echtzeitanwendungen
Pflege des MATLAB/Simulink-Testframeworks, Spezifizieren von Testkriterien, Testfällen und Testszenarien
dSPACE GmbH - Paderborn

Softwareentwickler MATLAB/Simulink (w/m)
Erarbeitung von Lösungen im Bereich der Schnittstelle zum Simulink-Modell und der Benutzeroberfläche von TargetLink
dSPACE GmbH - Paderborn

Testingenieur (w/m) Konfigurationswerkzeuge für Echtzeitsysteme
Einbinden von Simulink®-Simulationsmodellen, Verteilung der Simulationsmodelle auf Multicore- und Multiprozessorsysteme
dSPACE GmbH - Paderborn

Entwicklungsingenieur/-in elektrische Antriebe
Design und Test von embedded Software mit Methoden des Software-Engineerings
ZF Friedrichshafen AG - Friedrichshafen

Systemingenieur/in als Arbeitspaketverantwortlicher im Bereich HIL Automotive
Erstellung von Testfallspezifikationen und Testfällen
ESG Elektroniksystem- und Logistik-GmbH - Ingolstadt
weitere Angebote

Partner:




Vermarktungspartner


Forum
      Option
[Erweitert]
  • Diese Seite per Mail weiterempfehlen
     


Gehe zu:  
Neues Thema eröffnen Neue Antwort erstellen

Bug in mxGetString und mxArrayToString in R14SP3
 

approx
Forum-Newbie
Forum-Newbie

Beiträge: 2
Anmeldedatum: 27.07.07
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 27.07.2007, 09:09     Titel: Bug in mxGetString und mxArrayToString in R14SP3
  Antworten mit Zitat      
Hallo,

habe diese Woche ein mex-Interface nach Matlab7 portiert. Funktionierte
unter Matlab6.5 fuer Windows.

Folgender unter Matlab 6.5 funktionierender Codeausschnitt aus meinem
mex-File:

void mexFunction(int nlhs, mxArray *plhs[],int nrhs, const mxArray *prhs[]) {
unsigned char *buffer;

/* input must be a string */
if (mxIsChar(prhs[0]) != 1) {
mexErrMsgTxt("Input must be a string.");
}

buflen = (mxGetM(prhs[0]) * mxGetN(prhs[0])) + 1;

/* allocate memory */
buffer=mxCalloc(buflen, sizeof(char));

status = mxGetString(prhs[0], buffer, buflen);
}

Auf Buffer steht dann der an die Mexfunktion uebergebende String.
Folgender Aufruf in Matlab ist nun fehlerhaft:
>> mexFkt(char([0 0 150 67]))

Fuer den Char-Wert 150 wird durch mxGetString bzw. mxArrayToString
ein anderer Wert erzeugt, was nicht sein darf. Dieser Fehler tritt lediglich
fuer bestimmte char-Werte auf, einige werden korrekt konvertiert.

Ich habe das Problem geloest, in dem ich die Konvertierung selbst mache:

// anstelle von mxGetString
for (i=0;i<Buflen-1;i++) {
Buffer[i] = (unsigned char)(((short*)(mxGetData(prhs[0])))[i]);
}
Buffer[Buflen-1] = '\0';

Ich will mit diesem Post sicherstellen, ob sich der oben beschriebene Fehler
tatsaechlich auch bei anderen reproduzieren laesst und es sich somit
sicher um einen Bug in mxGetString und mxArrayToString handelt.

Unter Linux konnte ich noch nicht testen. Auf jeden Fall sind hoehere
Versionen 2007a ebenfalls betroffen.

Habe das beschriebene Problem auch hier gefunden und meine Alternative gepostet.
http://www.mathworks.com/matlabcent.....view_thread/151500#385172
Private Nachricht senden Benutzer-Profile anzeigen


approx
Themenstarter

 Forum-Newbie
Forum-Newbie

Beiträge: 2
Anmeldedatum: 27.07.07
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 06.08.2007, 10:43     Titel: mxGetString, mxArrayToString
  Antworten mit Zitat      
Habe die Anfrage auch an den Matlab-Support gestellt, hier die Antwort:

>>MATLAB uses unicode to represent character data.
>>When using the mxArrayToString
>>function it is converting
>>the unicode character into the default encoding of MATLAB which
>>on my machine is windows-1252.

>>The character mapping of windows-1252

>>http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT

>>shows that unicode 150 (0x96) is 0x2013 and will not
>>fit in a char in C. I suspect the ICU
>>library function converts this to 26 which is what
>>you get for characters that cannot be
>>displayed. This is also true for some other unicode characters.

>>The behavior is also similar to the unicode2native MATLAB function.

Somit reicht es anstelle von chars einen uint8-Vektor zu uebergeben, oder die oben
gezeigte Methode anzuwenden. Es ist also kein bug, sondern ein zunaechst
unerwartetes Verhalten. Unerwartet deshalb, da Vorgaengerversionen (Matlab6.5)
diese Konvertierung mit dem von mir erwarteten Verhalten vornahmen.

Es ist aber auf jeden Fall obiges bei entsprechenden Ports auf hoehere Matlab-
Versionen zu beachten.
Private Nachricht senden Benutzer-Profile anzeigen
 
Neues Thema eröffnen Neue Antwort erstellen



Options and Permissions
Beiträge der letzten Zeit anzeigen:

 Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
.


goMatlab ist ein Teil des goForen-Labels
goForen.de goMATLAB.de goLaTeX.de goPCB.de


 Impressum  | Werbung/Mediadaten | Studentenversion | FAQ | goMatlab RSS Button RSS


Copyright © 2007 - 2012 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
Partner: LabVIEWforum.de

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.