icheck (ein API checker) meldet mir wenn ich einen Enumerator hinzufüge dass
das API nicht vorwärts-kompatibel ist[0].

Das glaube ich auch gerne, wenn ich irgendwo eine Zahl von diesem Enum aus
dem erweiterten Bereich zurückgeben würde. So wie ich den Output aber
interpretiere reicht das Hinzufügen alleine aber um nicht mehr API
Kompatibel zu sein?

Hat jemand Erfahrung mit enums die direkt im öffentlichen Interface stehen?
So wie ich das verstehe ändert sich ja nicht der Typ wenn ich etwas bei
einem enum hinzufüge, sondern maximal der Bereich. Das trifft aber in
diesem Fall auch nicht zu, da ja bis 40 sowieso schon definiert war und nur
21 hinzugekommen ist.

Obwohl icheck nicht direkt dazu eine Aussage macht, würde ich meinen dass
das Interface dann nicht mehr rückwärts-kompatibel sein kann, weil ein
Programm welches den neuen Enumerator verwendet nicht mehr mit der alten
Version kompiliert werden kann.

Nehme ich das richtig an?
Darf ich, obwohl ich kompatibel bleiben will, einen Enumerator in einer
neuen API Version hinzufügen?
Darf der auch ausserhalb des Wertebereiches des alten enums liegen?
(in dem Beispiel KEY_TYPE_NEW=41).

mfg Markus

[0] API addition: enumerator KEY_TYPE_INT is new
in declaration at kdbnew.h:48:
typedef enum
{
KEY_TYPE_UNDEFINED = 0,
KEY_TYPE_BINARY = 20,
KEY_TYPE_BINARY01 = 21,
KEY_TYPE_INT = 21,
KEY_TYPE_STRING = 40,
} type_t;
versus declaration at kdb.h:48:
typedef enum
{
KEY_TYPE_UNDEFINED = 0,
KEY_TYPE_BINARY = 20,
KEY_TYPE_BINARY01 = 21,
KEY_TYPE_STRING = 40,
} type_t;

API is not forward-compatible

Markus Raab schrieb:
> icheck (ein API checker) meldet mir wenn ich einen Enumerator hinzufüge dass
> das API nicht vorwärts-kompatibel ist[0].

http://en.wikipedia.org/wiki/Forward_compatibility
# Forward compatibility (sometimes confused with extensibility) is
# the ability of a system to gracefully accept input intended for
# later versions of itself.

> [...]
> Obwohl icheck nicht direkt dazu eine Aussage macht, würde ich meinen dass
> das Interface dann nicht mehr rückwärts-kompatibel sein kann, weil ein
^^^^^^^^^^^^^^^^^^^^
Das wäre "backward compatibility".

> [...]
> [0] API addition: enumerator KEY_TYPE_INT is new
> in declaration at kdbnew.h:48:
> typedef enum
> {
> KEY_TYPE_UNDEFINED = 0,
> KEY_TYPE_BINARY = 20,
> KEY_TYPE_BINARY01 = 21,
> KEY_TYPE_INT = 21,

Früher war 21 eindeutig KEY_TYPE_BINARY01, jetzt ist es zweideutig.
Was genau bezweckst du damit?

--
usingwhitespaceisracism

Alexander Bartolich <alexander.bartolich@gmx.at> writes:
> Markus Raab schrieb:
>> icheck (ein API checker) meldet mir wenn ich einen Enumerator hinzufüge dass
>> das API nicht vorwärts-kompatibel ist[0].
>
> http://en.wikipedia.org/wiki/Forward_compatibility
> # Forward compatibility (sometimes confused with extensibility) is
> # the ability of a system to gracefully accept input intended for
> # later versions of itself.

'icheck' ist ein Debian-Utility und die man page definiert 'forward
compatibility' als 'things compiled against the old version will work
with the new' und 'backward compatibility' als 'things compiled
against the new version will work with the old', also genau umgekehrt.

Das scheint mir auch etwas sinnvoller als der von Dir zitierte Text,
denn ein solches 'vorwaertskompatibles System' kann es gar nicht
geben, weil es schlicht unmoeglich ist, Eingabedaten in einem
unbekannten Format als gueltige Eingaben zu akzeptieren. Bestenfalls
kan man unbekannte Teile einer zusammengesetzten Nachricht ignorieren
und hoffen, dass das, was sie an scheinbar bekanntem enthaelt, auch
alleine noch einen Sinn ergibt.

Alexander Bartolich wrote:

> Markus Raab schrieb:
>> icheck (ein API checker) meldet mir wenn ich einen Enumerator hinzufüge
>> dass das API nicht vorwärts-kompatibel ist[0].
>
> http://en.wikipedia.org/wiki/Forward_compatibility

Also wie bereits von Rainer Weikusat bemerkt, verwende ich die Bedeutung von
icheck.

>> [...]
>> Obwohl icheck nicht direkt dazu eine Aussage macht, würde ich meinen dass
>> das Interface dann nicht mehr rückwärts-kompatibel sein kann, weil ein
> ^^^^^^^^^^^^^^^^^^^^
> Das wäre "backward compatibility".

Genau.

>> [...]
>> [0] API addition: enumerator KEY_TYPE_INT is new
>> in declaration at kdbnew.h:48:
>> typedef enum
>> {
>> KEY_TYPE_UNDEFINED = 0,
>> KEY_TYPE_BINARY = 20,
>> KEY_TYPE_BINARY01 = 21,
>> KEY_TYPE_INT = 21,
>
> Früher war 21 eindeutig KEY_TYPE_BINARY01, jetzt ist es zweideutig.
> Was genau bezweckst du damit?

Ich weiß derzeit noch nicht welche Typen notwendig sind (sonst würde ich mir
über das Thema keine Gedanken machen). Die Idee war dass man bereits für
alle Werte ein dummy macht und dann Aliase dafür einführt wenn man weiß für
was der Wert wirklich steht.

Aber selbst das Einführen des Aliases führt laut icheck zu dem "forward
compatibility" Fehler also kann ich es mir auch gleich sparen. Die Idee
weitergeführt wäre dass ich es nicht mehrdeutig mache, sondern mit einem
#define KEY_TYPE_INT KEY_TYPE_BINARY01
einfach nach dem enum den gewünschten Namen mit dem dummy ersetze. Oder
manövriere ich mich da gerade in eine Sackgasse?

mfg Markus

Markus Raab schrieb:
> [...]
> Ich weiß derzeit noch nicht welche Typen notwendig sind (sonst würde ich mir
> über das Thema keine Gedanken machen). Die Idee war dass man bereits für
> alle Werte ein dummy macht und dann Aliase dafür einführt wenn man weiß für
> was der Wert wirklich steht.

Wozu soll das gut sein?

> Aber selbst das Einführen des Aliases führt laut icheck zu dem "forward
> compatibility" Fehler also kann ich es mir auch gleich sparen. Die Idee
> weitergeführt wäre dass ich es nicht mehrdeutig mache, sondern mit einem
> #define KEY_TYPE_INT KEY_TYPE_BINARY01
> einfach nach dem enum den gewünschten Namen mit dem dummy ersetze. Oder
> manövriere ich mich da gerade in eine Sackgasse?

Du willst:
a) eine binärkompatibel erweiterbare Schnittstelle
b) zentrale Verwaltung der verwendeten Werte
c) sprechende Namen im Quellcode
d) eine Bestätigung von $TOOL, dass alles super ist

Lösung:

typedef int type_t;
enum
{
KEY_TYPE_UNDEFINED = 0,
KEY_TYPE_BINARY = 20,
KEY_TYPE_BINARY01 = 21,
KEY_TYPE_INT = 21,
KEY_TYPE_STRING = 40,
};

--
usingwhitespaceisracism

Rainer Weikusat schrieb:
> [...]
> Das scheint mir auch etwas sinnvoller als der von Dir zitierte Text,
> denn ein solches 'vorwaertskompatibles System' kann es gar nicht
> geben, weil es schlicht unmoeglich ist, Eingabedaten in einem
> unbekannten Format als gueltige Eingaben zu akzeptieren.

Gruppenspezifisches Gegenbeispiel: #pragma

In Oracles PL/SQL werden "Optimizer Hints" in Kommentaren untergebracht.

In HTML werden Kommentare zur Einbettung von
- Cascading Style Sheets
- Server Side Includes
- Script-Sprachen wie JavaScript
verwendet.

In XML kann man mit einem zusätzlichen "namespace" zusätzliche Attribute
oder Entities einfügen, ohne damit eine etwaige Dokument-Validierung zu
stören.

--
usingwhitespaceisracism

Alexander Bartolich <alexander.bartolich@gmx.at> writes:
> Rainer Weikusat schrieb:
>> [...]
>> Das scheint mir auch etwas sinnvoller als der von Dir zitierte Text,
>> denn ein solches 'vorwaertskompatibles System' kann es gar nicht
>> geben, weil es schlicht unmoeglich ist, Eingabedaten in einem
>> unbekannten Format als gueltige Eingaben zu akzeptieren.
>
> Gruppenspezifisches Gegenbeispiel: #pragma

Ah ja. Und welche C-Implementierung 'akzeptiert' unbekannte pragmas
(das ist etwas anderes, als sie zu ignorieren). Und wieso akzeptiert
sie nur unbekannte #pragmas neuerer Compiler, aber keine unbekannten
#pragmas aelterer Compiler? Und wie wird das ueberhaupt festgestellt,
ob der unbekannte Text des #pragmas jetzt akzeptiert werden muss (weil
er aus der relativen Zukunft einer Implementierung kommt) oder zB zu
einem Uebersetzungsfehler fuehren sollte, weil es sich umgekehrt
verhaelt?

> In Oracles PL/SQL werden "Optimizer Hints" in Kommentaren
> untergebracht.

Der 'Inhalt' von Kommentaren wird von dem, was die Programmiersprache,
die es als Kommentar definiert, verarbeitet, ueberhaupt nicht weiter
beachtet.

Alexander Bartolich wrote:

> Markus Raab schrieb:
>> [...]
>> Ich weiß derzeit noch nicht welche Typen notwendig sind (sonst würde ich
>> mir über das Thema keine Gedanken machen). Die Idee war dass man bereits
>> für alle Werte ein dummy macht und dann Aliase dafür einführt wenn man
>> weiß für was der Wert wirklich steht.
>
> Wozu soll das gut sein?
>
>> Aber selbst das Einführen des Aliases führt laut icheck zu dem "forward
>> compatibility" Fehler also kann ich es mir auch gleich sparen. Die Idee
>> weitergeführt wäre dass ich es nicht mehrdeutig mache, sondern mit einem
>> #define KEY_TYPE_INT KEY_TYPE_BINARY01
>> einfach nach dem enum den gewünschten Namen mit dem dummy ersetze. Oder
>> manövriere ich mich da gerade in eine Sackgasse?
>
> Du willst:
> a) eine binärkompatibel erweiterbare Schnittstelle
> b) zentrale Verwaltung der verwendeten Werte
> c) sprechende Namen im Quellcode
> d) eine Bestätigung von $TOOL, dass alles super ist

e) Typsicherheit dass das richtige Enum übergeben wird

> Lösung:
>
> typedef int type_t;
> enum
> {
> KEY_TYPE_UNDEFINED = 0,
> KEY_TYPE_BINARY = 20,
> KEY_TYPE_BINARY01 = 21,
> KEY_TYPE_INT = 21,
> KEY_TYPE_STRING = 40,
> };

Von der Lösung wollte ich eigentlich gerade weg damit man nicht Werte von
anderen enums übergeben kann (ja es gibt einige mehr als type_t). Ausserdem
kommt mir das ein wenig vor als würde man es nur umschreiben damit es das
Tool nicht mehr kapiert.

Entweder die Erweiterung von Enums verursacht API/ABI Probleme, dann wüsste
ich natürlich gern welche und ob man vielleicht trotzdem damit umgehen
kann, oder icheck ist nur ein bisschen zu verbose (Es werden struct, union
und enum anscheinend gleich behandelt, stimmt das überhaupt?).

Aber trotzdem vielen Dank.

mfg Markus

Markus Raab schrieb:
> [...]
> Von der Lösung wollte ich eigentlich gerade weg damit man nicht
> Werte von anderen enums übergeben kann (ja es gibt einige mehr
> als type_t).

Ähem, genau das hast du aber vor. Wenn du neuen Code gegen die
jetzige Bibliotheksversion linkst, dann kann der neue Code Werte
übergeben, die die jetzige Version nicht kennt.

Um diese Art von Kompatibilität zu erreichen darfst du dich nicht
darauf verlassen, dass der Compiler niemanden ungültige Werte über-
geben lässt, sondern musst es explizit prüfen.

--
usingwhitespaceisracism

Markus Raab <usenet@markus-raab.org> writes:
> Alexander Bartolich wrote:
>> Markus Raab schrieb:
>>> [...]
>>> Ich weiß derzeit noch nicht welche Typen notwendig sind (sonst würde ich
>>> mir über das Thema keine Gedanken machen). Die Idee war dass man bereits
>>> für alle Werte ein dummy macht und dann Aliase dafür einführt wenn man
>>> weiß für was der Wert wirklich steht.
>>
>> Wozu soll das gut sein?
>>
>>> Aber selbst das Einführen des Aliases führt laut icheck zu dem "forward
>>> compatibility" Fehler also kann ich es mir auch gleich sparen. Die Idee
>>> weitergeführt wäre dass ich es nicht mehrdeutig mache, sondern mit einem
>>> #define KEY_TYPE_INT KEY_TYPE_BINARY01
>>> einfach nach dem enum den gewünschten Namen mit dem dummy ersetze. Oder
>>> manövriere ich mich da gerade in eine Sackgasse?
>>
>> Du willst:
>> a) eine binärkompatibel erweiterbare Schnittstelle
>> b) zentrale Verwaltung der verwendeten Werte
>> c) sprechende Namen im Quellcode
>> d) eine Bestätigung von $TOOL, dass alles super ist
>
> e) Typsicherheit dass das richtige Enum übergeben wird

'enumerated types' gehoeren in C zu den Integer-Typen (6.2.5|17). Das
bedeutet, dass die Werte, aus denen ein Aufzaehlungstyp sich
zusammensetzt, bei Bedarf genauso automatisch in andere arithmetische
Typen umgewandelt werden, wie das bei anderen Ganzzahltypen auch
stattfindet.

Etwas weniger geschwollen ausgedrueckt: Mit 'enum' definiert man
Integer-Konstanten. Weiter nichts.

>> Lösung:
>>
>> typedef int type_t;
>> enum
>> {
>> KEY_TYPE_UNDEFINED = 0,
>> KEY_TYPE_BINARY = 20,
>> KEY_TYPE_BINARY01 = 21,
>> KEY_TYPE_INT = 21,
>> KEY_TYPE_STRING = 40,
>> };
>
> Von der Lösung wollte ich eigentlich gerade weg damit man nicht Werte von
> anderen enums übergeben kann (ja es gibt einige mehr als type_t).

Dafuer wirst Du entweder eine andere Sprache als C benutzen muessen
(die 'ueblichen verdaechtigen' waeren Pascal oder Ada, wahrscheinlich
auch andere Gaststaettenbetreiber-Idiome, aka 'Modula-N'). Fuer
C-Quellen kannst Du hoechstens externe 'Stil-Checker' benutzten, die
Dir mitteilen, wenn der Code soetwas tut. Wie 'icheck' in diesem Fall:
Ein Aufzahlungstyp ist als Menge von Werten mit zugeordneten
symbolischen Namen definiert, dh zwei ungleiche Mengen sind auch zwei
unterschiedliche Typen. Ob die jetzt eine Schnittmenge haben und
woraus der Text, der den einen beschreibt, sich historisch entwickelt
hat (dh welcher andere Text geaendert wurde, um zu der momentanen
Beschreibung zu kommen) spielt dafuer keine Rolle.

> Ausserdem kommt mir das ein wenig vor als würde man es nur
> umschreiben damit es das Tool nicht mehr kapiert.

Man haette es dadurch so umgeschrieben, dass der 'logische
Typkonflikt' beseitigt waere.

> Entweder die Erweiterung von Enums verursacht API/ABI Probleme, dann wüsste
> ich natürlich gern welche

Wenn eine Unterroutine einen Parameter eines bestimmten
Aufzaehlungstyps uebernimmt und eine andere Version des Codes einen
gleichnamigen, anderen Typ benutzt, dann hat sich das API geaendert.