|
|
|
Bug in mxGetString und mxArrayToString in R14SP3 |
|
| approx |
Forum-Newbie
|
 |
Beiträge: 2
|
|
|
|
Anmeldedatum: 27.07.07
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
 |
|
Verfasst am: 27.07.2007, 08:09
Titel: Bug in mxGetString und mxArrayToString in R14SP3
|
 |
| |
 |
 |
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
|
|
|
|
|
|
| approx |
Themenstarter
Forum-Newbie
|
|
Beiträge: 2
|
|
|
|
Anmeldedatum: 27.07.07
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 06.08.2007, 09:43
Titel: mxGetString, mxArrayToString
|
|
| |
|
|
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.
|
|
|
|
|
|
|
Einstellungen und Berechtigungen
|
|
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
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2024
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
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.
|
|
