Pointer Berechnung schlägt fehl

Th69

Der Datentyp 'wchar_t' hat nichts direkt mit Unicode zu tun und die Größe ist Compiler-spezifisch!
Nimm statt wchar_t besser char32_t, s.a. Wide character: C/C++.

Th69 schrieb:

Nimm statt wchar_t besser char32_t, s.a. Wide character: C/C++.

Ja würde ich gerne nur leider gibt es diesen anscheinend nicht unter AIX 5.1. Könnte mir diesen höchstens selber definieren.

dachschaden

Dann nimmt halt int32_t . Am Ende arbeitest du eh nur wieder mit 4-Byte-Werten.

Intern ist wchar_t meist auch nichts anderes als ein int16_t .*

EDIT: *Nein, stimmt nicht. Auf Windows schon. Auf Linux sind wir wieder bei 4 Byte pro Zeichen. Aber Linux verwendet ja in der Hauptsache eh UTF-8, nicht UTF-16 oder UTF-32.

Ich wundere mich hier ein bisschen über die fehlende Exaktheit im Wording:

Unicode String in dem Format "two Bytes per Char" ... in den Standard "four Bytes per Char"

Meinst du damit UTF-16 und UTF-32 (BE oder LE)?

Wenn ja: UTF-16 ist NICHT 2 Bytes pro Char, sondern mindestens 2 Bytes pro Char. Es gibt auch Zeichen, die in UTF-16 mit 4 Bytes kodiert werden. Wenn du einfach so Nullen auffüllst, beachtest du das nicht richtig.

dachschaden schrieb:

Dann nimmt halt int32_t . Am Ende arbeitest du eh nur wieder mit 4-Byte-Werten.

Eben. Deswegen würde ich in meinem Fall lieber den wchar_t bevorzugen, da auf einem Rechner kompiliert wird und diese Binary dann auf alle Server verteilt wird die diese brauchen. Aus dem ganz einfachen Grund, dass die ganzen String Funktionen auf dem wchar aufsetzen. Klar man könnte Casten aber warum sich die mühe machen wenn es auch einfach geht?

dachschaden schrieb:

Intern ist wchar_t meist auch nichts anderes als ein int16_t .*

EDIT: *Nein, stimmt nicht. Auf Windows schon. Auf Linux sind wir wieder bei 4 Byte pro Zeichen. Aber Linux verwendet ja in der Hauptsache eh UTF-8, nicht UTF-16 oder UTF-32.

Unter 64Bit AIX ist es ein unsigned int und unter 32 Bit ist es ein unsigned short.

wob schrieb:

Ich wundere mich hier ein bisschen über die fehlende Exaktheit im Wording:

Unicode String in dem Format "two Bytes per Char" ... in den Standard "four Bytes per Char"

Meinst du damit UTF-16 und UTF-32 (BE oder LE)?

Wenn ja: UTF-16 ist NICHT 2 Bytes pro Char, sondern mindestens 2 Bytes pro Char. Es gibt auch Zeichen, die in UTF-16 mit 4 Bytes kodiert werden. Wenn du einfach so Nullen auffüllst, beachtest du das nicht richtig.

Ich bin Neuling in dem Thema Unicode und Co und Google Suchen haben mir zumindest gezeigt, dass oftmals vier Byte pro Char benutzt werden. Kann mir natürlich auch totalen Mist durchgelesen haben
In diesem Fall erweitere ich eine Programmiersprache Namens Natural, welche eine C-Api anbietet. An diese kann man alle Variablen weitergeben die in einem Natural Programm deklariert wurden. Es gibt einen Variablen Typ welcher sich Unicode schimpft und dieser wird Natural Intern anscheinend mit zwei Byte pro Char gehandelt. Leider gibt es über die Interne Funktionsweise kaum bis keine Dokumentation.
Kurz um: Ich weiß nicht mit welchem UTF-* intern gearbeitet wird. Ich weiß nur, dass die "neuen" String Funktionen mit einem wchar arbeiten und dann war für mich der nächste Logische Schritt die Sachen in ein Format zu bringen, in dem es einfach Funktioniert.

Wutz

audacity363_4 schrieb:

> Klar man könnte Casten aber warum sich die mühe machen wenn es auch einfach geht?

> Google Suchen haben mir zumindest gezeigt, dass oftmals vier Byte pro Char benutzt werden.

> in dem es einfach Funktioniert.

wchar_t ist gemäß C Standard hinsichtlich der Größe implementierungsabhängig, aber (implizit) größer char, d.h. ein Cast von char* auf wchar_t* ist schon mal UB.
Die Byte-Order ist ebenso implementierungsabhängig, und unter diesen Gesichtpunkten kann überhaupt nichts "einfach funktionieren" so wie du es dir vorstellst.
Ebenso musst du sicherstellen dass deine Compilier-Umgebung exakt der/den Produktionsumgebung entspricht.

Auch ist es implementierungsabhängig, ob wchar_t signed oder unsigned ist und ebenso sollte man bei solchen "Konvertierungen" wie du sie vorhast darauf achten, dass auch das Ende einer stringinterpretierenden wchar_t Folge ein wchar_t ist und somit kein einfaches '\0'.

Wenn du also z.B. in deiner C-Api-basierten externen Lib mit wchar_t - Funktionen hantierst (z.B. bei Strings) musst du sicherstellen, dass diese C-Funktionen identisch mit Multichar-Folgen umgehen wie dein Natural, deine Vorstellungen "es soll einfach funktionieren" oder gar "casten" sind bestenfalls Bastlerniveau.

Merke: Der C-Standard-Typ wchar_t und deren Funktionen wissen nichts von UTF-irgendwas, Unicode oder sonstwas, das musst du in der Compilerdokumentation unter "Implementierungsabhängiges" nachlesen und entscheiden, ob das dort Genannte zu deiner Hostsprache passt (was schwierig werden dürfte, da du die Hostsprachen-Details ja wohl nicht kennst).

Naja, wenn man es nicht exakt weiß, womit man hantiert und wenn man es auch nicht nachlesen kann, dann würde ich doch mal empfehlen, verschiedene Varianten durchzutesten.

Besonders viel Freude wird sowas wie der Violinschlüssel (siehe z.B. https://de.wikipedia.org/wiki/UTF-16#Beispiele) bereiten: U+1D11E - wenn der und auch andere Beispiele wie der Leerstring und ein paar weitere Texte richtig funktionieren, ist die Wahrscheinlichkeit hoch, dass das Konvertieren richtig funktioniert.

Wutz

Programmieren durch Ausprobieren!
Ich gehe mal davon aus, dass jemand der mit AIX+Natural hantiert, nicht im privaten Umfeld unterwegs ist, und Firmen sollten schon Dokumentation über Ihre Handwerkzeuge besitzen;
oder sie beichten dann ihren Kunden, dass für deren Software gerade ein Neuling auf Forschungsreise ist;-)

Wutz schrieb:

Programmieren durch Ausprobieren!

Nennt sich "Test Driven Development"

Man erstellt genügend viele Tests und manipuliert dann solange am Code herum, bis alle Tests durchlaufen.

Danach drückt man dann die Daumen, dass der Code auch für alle anderen Fälle korrekt ist und kein überraschendes Laufzeitverhalten zeigt. Oder habe ich TDD da falsch verstanden?

Funktioniert in der Realität erstaunlich gut, vor allem, weil es oft mangelhafte oder gar falsche Dokumentation gibt.

Firmen sollten

Genau, sollten... Der Anfang vom Ende.

Kommt natürlich immer auch ein bisschen auf den Bereich an, in dem man sich so bewegt. Kunden versprechen mir auch oft, Daten in UTF-8 zu liefern. Was dann hier ankommt, ist von dem Versprechen aber recht unabhängig. Wenn ich auf Kundendokumentation vertrauen würde, könnte ich überhaut nicht richtig arbeiten.

Auf Compilerdoku und dergleichen sollte man sich aber natürlich schon verlassen können, nicht dass du mich falsch verstehst.

So nach einem Kurzurlaub jetzt noch einmal frisch ans Werk.

Wutz schrieb:

Programmieren durch Ausprobieren!
Ich gehe mal davon aus, dass jemand der mit AIX+Natural hantiert, nicht im privaten Umfeld unterwegs ist, und Firmen sollten schon Dokumentation über Ihre Handwerkzeuge besitzen;
oder sie beichten dann ihren Kunden, dass für deren Software gerade ein Neuling auf Forschungsreise ist;-)

Da gehst du richtig von aus. Allerdings ist die SoftwareAG, welche Natural entwickelt und vertreibt, zugeknöpfter als Apple oder Konsorten. Die Doku ist leider im Folgenden Wortlaut geschrieben:

Da übergibst du einen Buffer und dann stehen da deine Daten drin.

Wie die Daten da rein kommen, woher sie kommen und wie sie formatiert sind muss man sich selber über HexDumps bzw. debugging des ASM Codes der Schnittelle erarbeiten. (Bei den Meisten Sachen ist es zum Glück klar, aber die kennen beispielsweise kein '\0' und füllen den restlichen Buffer einfach mit Spaces).

dachschaden

audacity363_4 schrieb:

Da übergibst du einen Buffer und dann stehen da deine Daten drin.

Entweder du verstehst die Doku nicht, oder ihr habt euch über den Tisch ziehen lassen.

Wenn man ein geschlossenes System vertreibt, dann hat da auch eine ausführliche Dokumentation beizuliegen, mit der selbst ein Depp (relativ gesehen) versteht, welche Knöpfe man wie drücken muss, damit was passiert.

Wutz

Also zunächst mal:
Ein String (sehr beliebtes Datenkonstrukt auch für heterogene Datenaustausche wie bei dir der Fall) ist nichts anderes als eine Bytefolge mit Encoding.
Wenn du das Encoding nicht kennst, hast du prinzipiell verloren, Ausprobieren hilft nicht, du kannst in Tests nicht alle Produktionssituationen simulieren.
- frag deinen Chef, was du machen sollst
- frag deinen Kunden, ob er damit einverstanden ist, mit seiner von euch gelieferten Software und seinen eigenen Daten in seiner produktioven Umgebung als Versuchskaninchen zur Verfügung zu stehen

Von meinen o.g. Kriterien kann man pragmatisch davon ausgehen, dass wohl zumindest 8-Bit-Bytes gemeint sind (im C-Jargon: CHAR_BIT=8),
dann hast du aber weiterhin noch mindestens die Probleme:
- das Encoding (du musst bei deinen Versuchen darauf hoffen, dass die SAG-Leute und deine Compiler-Leute das Gleiche damit meinen, wenn sie von einem Multichar-Stream sprechen)
- die Ende-Erkennung des Strings (bei UCS-2 muss dein Host 0x00 0x00 liefern, bzw. UCS-4 0x00 0x00 0x00 0x00), um ohne Tricks mit Standard-C Funktionen arbeiten zu können (deine genannte Variante "Auffüllen mit Spaces") kann ich mir nicht recht vorstellen, da ich der Meinung bin, bei SAG laufen nicht nur totale Vollhonks rum

dachschaden schrieb:

Entweder du verstehst die Doku nicht, oder ihr habt euch über den Tisch ziehen lassen.

Wenn man ein geschlossenes System vertreibt, dann hat da auch eine ausführliche Dokumentation beizuliegen, mit der selbst ein Depp (relativ gesehen) versteht, welche Knöpfe man wie drücken muss, damit was passiert.

Die Programmiersprache wird bei uns seit über 25 Jahren eingesetzt und da wird sich so schnell auch nichts dran ändern. An sich ist diese für unsere Anwendungen auch optimal, nur die C-Api wird in dieser Hinsicht vernachlässigt. Natural ist sehr High-Level gehalten und dementsprechend ist die C-Api auch für Noobs geschrieben worden und hat selbst nach über 20 Jahren noch Bugs, weil viele sie nicht benutzen bzw. SAG sich nicht wirklich darum kümmert.

Ich bin gerade dabei ein Webframework für diese Programmiersprache zu schreiben, also muss ich diese Schnittstelle etwas missbrauchen. Sie war nie für solche Sachen vorgesehen(Es funktioniert aber mit etwas Trickserei).