Problem mit restrict & const Zeiger [gelöst]

[dakuan]

Ich versuche gerade einen Datum String im ISO Format in Unix Zeit zu konvertieren. wenn es dafür eine fertige Funktion geben sollte, wäre meine Frage aber noch nicht gelöst, weil ich dann ja immer noch eine Wissenslücke hätte.

Mein Codefragment sieht so aus:

Code: Alles auswählen

time_t date2uxtime( const char * dstr ) {
    struct tm   dt;
    long        val;
    const char * p = dstr;
    int         st = 1;
    time_t      uxtime;
    ---
    while( st ) {
        switch( st ) {
            case 1: // YYYY
                val = strtol( p, &p, 10 );
    ...

Das funktioniert zwar, aber der Compiler schüttet mich mit Warnungen zu.

Code: Alles auswählen

vtscan.c: In function ‘date2uxtime’:
vtscan.c:76:34: warning: passing argument 2 of ‘strtol’ from incompatible pointer type [-Wincompatible-pointer-types]
                 val = strtol( p, &p, 10 );
                                  ^
In file included from png_text.h:12:0,
                 from vtscan.c:20:
/usr/include/stdlib.h:176:17: note: expected ‘char ** restrict’ but argument is of type ‘const char **’
 extern long int strtol (const char *__restrict __nptr,

Was muss ich machen, um die Warnungen los zu werden?

[Meillo]

Ich denke, dass `p' nicht `const' sein darf, wenn du ihn als zweites Argument von strtol() veraendern willst.

Allgemein zieht `const' meist Rattenschwaenze hinter sich her ...

[dakuan]

Dann muss ich wohl irgendwo casten.

Ich hatte extra den Funktionskopf mit kopiert, damit der Zusammenhang sichtbar wird. Im Grunde ist der übergebene String ein Teil der Kommandozeile und wird durch getopt() bereit gestellt.

Ich hatte gehofft, dass es ohne Holzhammer (cast) geht.

[MSfree]

Ich hatte gehofft, dass es ohne Holzhammer (cast) geht.

Der zweite Parameter liefert einen Pointer zurück, der auf den Bereich hinter dem interprätierten Integer zeigt. Der kann also gar nicht const sein.

Da dich der Pointer aber vermutlich gar nicht interessiert, es sei denn, du willst den String weiter parsen, kannst du einfach eine locale (nicht const) Variable deklarieren,

Code: Alles auswählen

char *tmp;
strtol( p, &tmp, 10 );

[dakuan]

Doch, der Zeiger interessiert mich, da der String weiter zerlegt werden soll. Das zugrunde liegende Format sieht folgendermaßen aus:

Code: Alles auswählen

YYYY-MM-DDThh:mm:ss

Ich habe da also 6 Bereiche und muss dann auch die Trennzeichen prüfen und bei Fehlern vorzeitig abbrechen bevor ich am Ende mktime() aufrufe.

Eine neue Idee - Ich könnte den String kopieren, dann kann ich das const weg lassen. Finde ich aber auch doof.

[Meillo]

Ich hatte gehofft, dass es ohne Holzhammer (cast) geht.

Der zweite Parameter liefert einen Pointer zurück, der auf den Bereich hinter dem interprätierten Integer zeigt. Der kann also gar nicht const sein.

Genau.

Kann man einen nicht-const-Pointer ueberhaupt auf einen const-Pointer casten? Das macht doch keinen Sinn.

Da dich der Pointer aber vermutlich gar nicht interessiert, es sei denn, du willst den String weiter parsen, kannst du einfach eine locale (nicht const) Variable deklarieren,

Code: Alles auswählen

char *tmp;
strtol( p, &tmp, 10 );

Wenn nicht interessiert wie weit die Zahl im String gegangen ist, kann man den zweiten Parameter einfach auf NULL setzen.

Im konkreten Fall vermute ich schon, dass es relevant sein wird, den Parameter zu nutzen, weil (soweit ich das erkennen kann) aus einem String komponentenweise ein Datum extrahiert werden soll. Wenn man YYYY erkannt hat, folgt ein `tmp++' und dann ein `month = strtol(tmp, &tmp, 10)' ... usw., wuerde ich sagen.

... oder du verwendest strptime(3). (Verwendungsbeispiel in der Manpage)

[Meillo]

Unsere Posts haben sich ueberschnitten ...

Eine neue Idee - Ich könnte den String kopieren, dann kann ich das const weg lassen. Finde ich aber auch doof.

Das const im Funktionsparameter ist schon in Ordnung. Nur das beim lokalen Pointer `p' muss weg, weil der nicht const ist. Du legst in deinem Codeschnipsel einen zweiten konstanten Zeiger auf einen konstanten Zeiger an. Warum? Wenn du schon einen konstanten Zeiger hast, brauchst du keinen weiteren. Du brauchst nur dann einen weiteren, wenn dieser sich veraendern soll. Und genau das brauchst du eben: Einen Zeiger, der beim stueckweisen Parsen des Datums mitwandert und zeigt wie weit im String du schon etwas erkannt hast und wo du die naechste Zahl erkennen willst. Dafuer nimmst du einen (nicht-const) Zeiger, den du im zweiten Argument von strtol() setzen laesst und (nach einem ++, um ueber das Trennzeichen zu kommen) beim naechsten strtol()-Aufruf als erstes Argument verwendest.

[MSfree]

Kann man einen nicht-const-Pointer ueberhaupt auf einen const-Pointer casten? Das macht doch keinen Sinn.

Casten kann man so gut wie alles, mit einem mehr oder weniger häßlichen Syntax. Aber, wenn man die Sache mit einer tmp-Variable baut, kommt man auch ganz einfach an einem Cast vorbei.

... oder du verwendest strptime(3). (Verwendungsbeispiel in der Manpage)

strptime mache aus einem struct tm eine Datumsstring mit vorgebbarem Format. Hier soll ja der umgekehrte Weg gegangen werden, Datumstext in struct tm (oder einzelne Integer), dafür habe ich aber auf die schnelle keine Standardfunktion gefunden.

[Meillo]

Casten kann man so gut wie alles, mit einem mehr oder weniger häßlichen Syntax. Aber, wenn man die Sache mit einer tmp-Variable baut, kommt man auch ganz einfach an einem Cast vorbei.

Ja, den Cast braucht es nicht. Es muss nur das `const' vor der lokalen Variable `p' entfernt werden und der Code laeuft vermutlich so wie er beabsichtigt ist.

... oder du verwendest strptime(3). (Verwendungsbeispiel in der Manpage)

strptime mache aus einem struct tm eine Datumsstring mit vorgebbarem Format. Hier soll ja der umgekehrte Weg gegangen werden, Datumstext in struct tm (oder einzelne Integer), dafür habe ich aber auf die schnelle keine Standardfunktion gefunden.

Ich glaube, du irrst dich oder hast dich verlesen.

strftime(3) tut das was du beschreibst, strptime(3) ist das Gegenstueck:

The strptime() function is the converse function to strf-
time(3) and converts the character string pointed to by s to
values which are stored in the tm structure pointed to by
tm, using the format specified by format.

Edit:
Die Mnemonic ist: string-format-time und string-parse-time.

[dakuan]

Wow!

Ich bin ja etwas langsam und musste den Post von Meillo dreimal langsam durchlesen, um den Sachverhalt richtig zu erfassen. Aber der Knoten im Gehirn ist jetzt weg. Es funktioniert ohne Meckerei! Habe es jetzt so geändert:

Code: Alles auswählen

time_t date2uxtime( const char * dstr ) {
    struct tm   dt;
    long        val;
    char *      p;
    int         st = 1;
    time_t      uxtime;
    ...
    while( st ) {
        switch( st ) {
            case 1: // YYYY
                val = strtol( dstr, &p, 10 );
                ...
            case 2: // MM
                val = strtol( p, &p, 10 );
                ...

Du legst in deinem Codeschnipsel einen zweiten konstanten Zeiger auf einen konstanten Zeiger an. Warum?

Das ist eine dumme alte Gewohnheit. Ich hatte ganz früher mit Compilern zu tun, die es nicht erlauben, den übergebenen Parameter zu verändern. Ich glaube das war der Latice C-Compiler auf dem Atari-ST. Daher die Kopie des übergebenen Zeigers. Dein Vorschlag löst gleich alle solche Probleme.

Ich kämpfe da schon 3 Tage mit und bin jetzt froh doch endlich gefragt zu haben.

P.S. die Funktion strptime() kannte ich noch nicht. Ist in meinem Buch nicht aufgeführt. Werde ich aber auch noch ausprobieren. Musste ich aber auch 2-mal durchlesen da ich zuerst auf den Rückgabewert geschaut hatte.

P.S.2: Wie markiert man hier einen Thread auf gelöst? In einem anderen Forum gibt es dafür einen Button.

[Meillo]

Ich bin ja etwas langsam und musste den Post von Meillo dreimal langsam durchlesen, um den Sachverhalt richtig zu erfassen. Aber der Knoten im Gehirn ist jetzt weg. Es funktioniert ohne Meckerei!

Cool!

Habe es jetzt so geändert:

Code: Alles auswählen

time_t date2uxtime( const char * dstr ) {
    struct tm   dt;
    long        val;
    char *      p;
    int         st = 1;
    time_t      uxtime;
    ...
    while( st ) {
        switch( st ) {
            case 1: // YYYY
                val = strtol( dstr, &p, 10 );
                ...
            case 2: // MM
                val = strtol( p, &p, 10 );
                ...

Ich wuerde eine Sache aendern, naemlich das Argument gleich am Anfang `p' zuweisen und dann den Code unten nur mit `p' schreiben. Dann funktioniert er naemlich immer noch wenn du die Reihenfolge der Faelle mal aendern solltest. Ausserdem sind dann alle strtol() gleich.

Code: Alles auswählen

time_t date2uxtime( const char * dstr ) {
    struct tm   dt;
    long        val;
    char *      p = dstr;
    int         st = 1;
    time_t      uxtime;
    ...
    while( st ) {
        switch( st ) {
            case 1: // YYYY
                val = strtol( p, &p, 10 );
                ...
            case 2: // MM
                val = strtol( p, &p, 10 );
                ...

Ich kämpfe da schon 3 Tage mit und bin jetzt froh doch endlich gefragt zu haben.

P.S. die Funktion strptime() kannte ich noch nicht. Ist in meinem Buch nicht aufgeführt. Werde ich aber auch noch ausprobieren. Musste ich aber auch 2-mal durchlesen da ich zuerst auf den Rückgabewert geschaut hatte.

Die macht deine ganze Parserei halt auf einmal automatisch. Das wird deinen Code deutlich verkuerzen.

P.S.2: Wie markiert man hier einen Thread auf gelöst? In einem anderen Forum gibt es dafür einen Button.

Bei uns muss man das manuell machen: Deinen ersten Beitrag editieren und dort den Titel um ein ``[gelöst]'' ergaenzen.

(Edit: Vielleicht kannst du dann im Titel auch noch das Wort ``restrict'' durch ``const'' ersetzen, weil dort das Problem gelegen hat.)



Danke fuer deinen tollen Thread. Mir hat er viel Freude bereitet.

[dakuan]

Ich wuerde eine Sache aendern, naemlich das Argument gleich am Anfang `p' zuweisen und dann den Code unten nur mit `p' schreiben.

Hatte ich das nicht am Anfang. Da müsste ich doch wieder casten. Und die Reihenfolge ändert sich nicht, auch wenn ISO sich das anders überlegt. Nicht ISO Formate sind einfach schlecht handhabbar, wenn es um Berechnungen Kalenderdaten geht. Hier geht es um das Verfallsdatum von Thumbnaildateien.

Die macht deine ganze Parserei halt auf einmal automatisch.

Ja, aber da hätte ich nichts gelernt.

Bei uns muss man das manuell machen:

Ok, bei ubuntuusers.de geht das nicht, wenn bereits jemand geantwortet hat. deshalb da der Button.

Danke fuer deinen tollen Thread. Mir hat er viel Freude bereitet.

Bei ubuntuusers.de hätte ich dafür jede Menge Schelte bekommen, weil meine Denke und Herangehensweise angeblich völlig falsch sei. Deswegen bin ich da weg.

Und noch eine Korrektur: Der Compiler, der mich damals genervt hatte, war nicht Latice. Es war der Compiler, der damals mit Coherent mitgeliefert wurde.

[Meillo]

Ich wuerde eine Sache aendern, naemlich das Argument gleich am Anfang `p' zuweisen und dann den Code unten nur mit `p' schreiben.

Hatte ich das nicht am Anfang. Da müsste ich doch wieder casten.

Du hast Recht, es braeuchte dann einen Cast.

Ich finde Casts nicht schlimm, wenn sie Sinn machen (... dann sind sie naemlich sinnvoll ). Aber da ich eh nie const verwende, erspare ich mir diese Problemchen komplett. Einerseits verstehe ich schon den Sinn von const, aber immer wenn ich mal versucht habe damit einen sinnvollen Weg zu finden, dann hat es so einen Rattenschwanz gezogen, dass ich am Ende alles mit Casts voll hatte, was der Lesbarkeit stark geschadet hat. Dann habe ich es wieder gelassen. Bislang habe ich noch keine Nachteile davon gespuert.

Vielleicht kannst du mal von deinen Erfahrungen berichten, wenn du einerseits const verwendest und andererseits Casts meidest -- geht das ueberhaupt?


Fuer die Lesbarkeit und die Robustheit des Codes faende ich es sinnvoll, die Zuweisung oben zu machen und unten einheitliche strtol()-Aufrufe zu haben. Der Cast waere fuer mich ein kleiner Preis dafuer. Aber es ist ja dein Code und nicht meiner.

Die macht deine ganze Parserei halt auf einmal automatisch.

Ja, aber da hätte ich nichts gelernt.

Ach, wenn dir das wichtig ist, dann macht es natuerlich Sinn, es selber zu programmieren ... und anschliessend eine zweite Umsetzung mit strptime() zu schreiben, und die beiden dann zu vergleichen und daraus etwas fuer die Zukunft zu lernen.


Fuer meinen Geschmack haben wir deutlich zu wenige C-Programmierproblemchen hier, insofern darfst du gerne hin und wieder mit einem ankommen.

[dakuan]

Fuer meinen Geschmack haben wir deutlich zu wenige C-Programmierproblemchen hier, insofern darfst du gerne hin und wieder mit einem ankommen.

Das macht Mut. Ich bin nämlich zweigleisig unterwegs. Für einfache CLI Anwendungen bevorzuge ich C-Programme (wie dieses hier). Für GUI Anwendungen bin ich allerdings mit C++ (hier FLTK) unterwegs, womit ich auch immer wieder anecke.

Ich finde Casts nicht schlimm, wenn sie Sinn machen ...

Es gibt "Hardliner", die verteufeln das grundsätzlich. Aber es gibt auch Toolkits, da ist das Programm. Da werden viele Zeiger als void* übergeben. Da muss dann der Empfänger wissen, was da kommen soll.

Es gibt da Puristen und Pragmatiker.

Zur ersten Gruppe gehöre ich nicht.

[dakuan]

Fuer meinen Geschmack haben wir deutlich zu wenige C-Programmierproblemchen hier, insofern darfst du gerne hin und wieder mit einem ankommen.

Das macht Mut. Ich bin nämlich zweigleisig unterwegs. Für einfache CLI Anwendungen bevorzuge ich C-Programme (wie dieses hier). Für GUI Anwendungen bin ich allerdings mit C++ (hier FLTK) unterwegs, womit ich auch immer wieder anecke.

Ich finde Casts nicht schlimm, wenn sie Sinn machen ...

Es gibt "Hardliner", die verteufeln das grundsätzlich. Aber es gibt auch Toolkits, da ist das Programm. Da werden viele Zeiger als void* übergeben. Da muss dann der Empfänger wissen, was da kommen soll.

Es gibt da Puristen und Pragmatiker.

Zur ersten Gruppe gehöre ich nicht.

[eggy]

Fuer meinen Geschmack haben wir deutlich zu wenige C-Programmierproblemchen hier

Das lässt sich ändern: Meillo schreibt ab jetzt zu jedem scriptingcontest auch ne C-Variante

[Meillo]

Fuer meinen Geschmack haben wir deutlich zu wenige C-Programmierproblemchen hier, insofern darfst du gerne hin und wieder mit einem ankommen.

Das macht Mut. Ich bin nämlich zweigleisig unterwegs. Für einfache CLI Anwendungen bevorzuge ich C-Programme (wie dieses hier). Für GUI Anwendungen bin ich allerdings mit C++ (hier FLTK) unterwegs, womit ich auch immer wieder anecke.

Zu C++ oder FLTK kann ich nichts sagen, aber CLI C macht mir Spass.

Ich finde Casts nicht schlimm, wenn sie Sinn machen ...

Es gibt "Hardliner", die verteufeln das grundsätzlich. Aber es gibt auch Toolkits, da ist das Programm. Da werden viele Zeiger als void* übergeben. Da muss dann der Empfänger wissen, was da kommen soll.

Oder man uebergibt etwas, das selber ausweisen kann, was es enthaelt, wie diese Box:

Code: Alles auswählen

struct box {
        enum {
                CHARPRT,
                INTPTR,
                FLOATPTR,
        } type;
        union {
                char *c;
                int *i;
                float *f;
        } contents;
};

Es gibt da Puristen und Pragmatiker.

Die Leute legen halt auf unterschiedliche Dinge unterschiedlich viel Wert.

Ich habe gerade das const-Zeug nochmal genauer nachvollzogen. Nun, ich muss zugeben, dass es mir da doch ganz schoen das Hirn verdreht. Alleine die Unterschiede zwischen diesen vier Formen sind anstrengend genug:

Code: Alles auswählen

const char * cp
char const * cp
char * const cp
char const * const cp

(Die ersten zwei sind semantisch identisch: Ein veraendertlicher Zeiger auf einen konstanten Char. Dann ein konstanter Zeiger auf einen veraenderlichen Char. Und zuletzt ein konstanter Zeiger auf einen konstanten Char.)

Funktionszeigertypen zu entwirren macht mir dagegen deutlich mehr Spass.

Nunja, jedem das Seine ... und mir jetzt mein Bett.

[Meillo]

Fuer meinen Geschmack haben wir deutlich zu wenige C-Programmierproblemchen hier

Das lässt sich ändern: Meillo schreibt ab jetzt zu jedem scriptingcontest auch ne C-Variante

(Mist! )


... ach, eggy! Ich schlafe schon ... Hab das gar nicht mehr gelesen.

[Meillo]

Ich habe mich noch ein bisschen weiter mit const beschaeftigt und dabei das in der Wikipedia gefunden:

"Let me begin by saying that I'm not convinced that even the
pre-December qualifiers ('const' and 'volatile') carry their
weight; I suspect that what they add to the cost of learning and
using the language is not repaid in greater expressiveness.
'Volatile', in particular, is a frill for esoteric applications,
and much better expressed by other means. Its chief virtue is
that nearly everyone can forget about it. 'Const' is
simultaneously more useful and more obtrusive; you can't avoid
learning about it, because of its presence in the library
interface. Nevertheless, I don't argue for the extirpation of
qualifiers, if only because it is too late.

(`const' ist im Standardisierungsprozess fuer C89 aufgenommen worden. Wie mir scheint hat es seinen Ursprung in den Vorlaeufern von C++.)


Irgendwie verdreht mir die Sache immer noch den Kopf.

Wenn als Parameter ein `const char *dstr' kommt und man nicht casten will, habe ich keinen Weg gefunden bei strtol() bei Parameter eins und zwei den gleichen Pointer zu verwenden.

Dies ist die einzige Form, die unter diesen Vorgaben zu funktionieren scheint:

Code: Alles auswählen

#include <stdio.h>
#include <stdlib.h>

void date2uxtime(const char *dstr) {
        char *p;

        printf("year: %ld\n", strtol(dstr, &p, 10));
        p++;
        printf("month: %ld\n", strtol(p, &p, 10));
        p++;
        printf("day: %ld\n", strtol(p, &p, 10));
}

int main() {
        date2uxtime("2021-03-12");
        return 0;
}

Dabei wird der Wert, auf den der char-Pointer zeigt gar nicht veraendert. Folglich sollte es eigentlich moeglich sein, als zweiten Parameter einen `const char **' zu uebergeben -- geht aber nicht. Ich meine, man kann die technischen Gruende dafuer sicher irgendwann nachvollziehen, wenn man sich nur lange genug damit auseinander gesetzt hat, aber die Stimmigkeit und Konsistenz, die C sonst zu bieten hat, fehlt mir hier. Wahrscheinlich ist das normal fuer nachtraeglich aufgesetzte Konzepte.

Ich denke, dass ich darum `const' nicht verwende: Die Schoenheit und Eleganz von C geht verloren wenn man sich mit const einlaesst. Und da DMR auch nicht der Meinung war, dass const seine Kosten wert sei, kann ich es ganz beruhigt auch weiterhin meiden.

[eggy]

Irgendwie verdreht mir die Sache immer noch den Kopf.

Zu const in C++ gibts nen paar interessante Videos von der cppcon.
https://www.youtube.com/watch?v=Y1KOuFYtTF4 bei Minute 5:50
oder als PDF (Seite 21)
https://raw.githubusercontent.com/CppCo ... 202015.pdf
wie üblich find ich grade das Video was ich eigentlich suche grade nicht: von (wenn ich da nichts durcheinanderwerf) Kate Gregory hatte ich diesbezueglich mal nen sehr gut verständlichen Vortrag gehört, kann aber sein, dass sie eigentlich über was anderes gesprochen hat und das nur kleiner Nebenschauplatz war - vielleicht kennt oder findet den ja jemand per Zufall, wird so um 2017 rum gewesen sein, vielleicht.
Und vermutlich findest Du auch mehr als ne Handvoll Videos von Jason Turner zu dem Thema, falls man das mal aus Höhe des Compilers betrachten will, wären seine Videos die erste Anlaufstelle (ist nicht jedermans Fall).

Edit: https://www.youtube.com/watch?v=z6s6bacI424 "East const vs West const" - dazu gabs auch noch nen längeres Video, evtl ne Stunde oder so, vermutlich auch auf der cppcon

[dakuan]

Also const an sich finde ich gar nicht so schlimm, jedenfalls meistens. Bei C++ sehe ich das ständig. Es macht ja auch nicht immer Sinn, einen fremden Puffer (hier Kommandozeile), dessen Größe man nicht mal kennt, verändern zu wollen (oder zu können).

Aber dieses restrict finde ich überflüssig.

[eggy]

Mal etwas Hintergrund zu restrict:
https://openbook.rheinwerk-verlag.de/c_ ... er_013.htm
https://www.oracle.com/solaris/technolo ... trict.html
https://cellperformance.beyond3d.com/ar ... yword.html
Bei Stackoverflow gibts nen paar Threads dazu und ob die zusätzlichen Optimierungen des Compilers bei Verwedung von restricted spürbar sind: die einen sagen so, die anderen so.
Das Beispiel aus https://en.cppreference.com/w/c/language/restrict compiliert mit "gcc test.c -S -O3" spart hier jedenfalls auch nen add, ist auf den ersten Blick nicht viel, aber da kann schon einiges zusammenkommen.

[dakuan]

Den "Rheinwerk" Link kannte ich schon, der hat mich aber auch nicht weiter gebracht.

... compiliert mit "gcc test.c -S -O3" spart hier jedenfalls auch nen add, ist auf den ersten Blick nicht viel, aber da kann schon einiges zusammenkommen.

Ist wirklich nicht viel, hängt aber auch vom Multiplikator ab. In meinem Fall liegt der aktuell bei etwa 25000. Aber das Analysieren von Thumbnail Dateien ist sehr I/O lastig. Da ist die Festplatte der Bremser. Aber bei Bildverarbeitung sieht das schon anders aus.