Wickenhäuser: Error: integer expression must be constant

[Bastian N. (Firma: Privat) (seal)]

Hallo Forum,

ich programmiere gerade einen 8051er mit der IDE von Wickehäuser.
Leider gibt der Compiler nicht standardkonforme Nachrichten aus, sonst 
könnte ich einfach im Internet nach dem Fehler suchen...

Ich bekomme für die nachfolgende Funktion diese Fehlermeldung:
> Error: integer expression must be constant

int read_val(int length) {
  char input[length];
  inputse(input, length);
  return atoi(input);    
}

danach habe ich den Code so abgeändert:

int read_val(const int* length) {
  char input[length];
  inputse(input, length);
  return atoi(input);    
}

In der meinem Lehrbuch wird leider nur auf triviale Art und Weise der 
Aufbau von Funktionen behandelt. Also ohne den Parameter als Länge für 
ein Array zu verwenden. Nur so Sachen wie:

void fkt_1(unsigned int i)
{
printf("Funktion 1 wurde aufgerufen: %u\n\n",i);
}

Wie muss ich den Parameter/Funktion abändern, dass es funktioniert die 
Länge des char Arrays als Parameter zu übergeben?

(Die Funktion scanf fehlt übrigens im Wickenhäuser.)

[Baldrian (Gast)]

length muss zur Zeit der Übersetzung eine Konstante sein. Du 
verwendest eine Variable. D. h. du musst die Länge festlegen. Z. B:

#define length 10
char input[length];

[Tom K. (ez81)]

Bastian N. schrieb:
> char input[length];
Das ist ein variable length array (googlen) und erst sei C99 im 
Standard. Der Wickenhäuser-Compiler sieht nicht gerade aus, als ob 
solche neumodischen Dinge schnell umgesetzt würden.

Bastian N. schrieb:
> int read_val(const int* length) {
>   char input[length];
Das ergibt so keinen Sinn und sollte nicht compilieren.

[Bastian N. (Firma: Privat) (seal)]

Baldrian schrieb:
> length muss zur Zeit der Übersetzung eine Konstante sein. Du
> verwendest eine Variable. D. h. du musst die Länge festlegen. Z. B:
>
>
>

> #define length 10
> char input[length];
>

Hmm, das habe ich mir auch schon überlegt. Leider geht so die 
Flexibilität verloren.


Tom K. schrieb:
> Bastian N. schrieb:
>> char input[length];
> Das ist ein variable length array (googlen) und erst sei C99 im
> Standard. Der Wickenhäuser-Compiler sieht nicht gerade aus, als ob
> solche neumodischen Dinge schnell umgesetzt würden.
>
Also geht das nicht?
> Bastian N. schrieb:
>> int read_val(const int* length) {
>>   char input[length];
> Das ergibt so keinen Sinn und sollte nicht compilieren.
Kompiliert auch nicht :D


Sehe ich das richtig, das es nur wie Baldrian vorgeschlagen hat geht?

[R. F. (rfr)]

Stell mal fest, welchen Standard dein Compiler erfüllt, C99 ist das wohl 
eher nicht. Oder ändere deinen Code,  indem du das array und den Aufruf 
änderst.

[Bastian N. (Firma: Privat) (seal)]

R. F. schrieb:
> Stell mal fest, welchen Standard dein Compiler erfüllt, C99 ist das wohl
> eher nicht. Oder ändere deinen Code,  indem du das array und den Aufruf
> änderst.

Also bei Wickenhäuser steht folgendes:

ANSI C compiler
 Full support for the ANSI C language. NOT a reduced
subset of C or extended K&R C.
 Especially designed for ext. Harvard architectures.
 Include assembly language in your C programs.
 compiler writes 100% assembler sourcecode.
 Integral support for source level debugging.
 Superior code quality due to powerful optimizer.

Also ANSI C? Aber Wickenhäuser ist verdammt komisch. In der string.h 
steht nur folgendes:

/*******************************************
* string.h for uC/51 (C) 2002 Wickenhaeuser
*******************************************/

// ANSII standard
extern int strlen(far char* px);
extern int strcmp(far char* pa,far char* pb);
extern int memcmp(far char* pa,far char* pb, int n);
extern far char* strcpy(far char * pdst, far char * psrc);

// Non ANSI byte move (Note: src first argument!)
extern void bmove(far void * _psrc, far void * _pdest, unsigned int count);

/* END */

Leider muss ich das Teil für mein Studium (weil vorgegeben) verwenden.

Produktinfo: http://www.wickenhaeuser.de/uc51data/uc51_fly.pdf
Website: http://wickenhaeuser.de/_index.html

[R. F. (rfr)]

Dann ändere das array.

Gruss

Robert

[Bastian N. (Firma: Privat) (seal)]

Du meinst auf einen festen Wert? Mein Ziel ist es doch das flexibel zu 
halten..

[Johann L. (gjlayde)]

Bastian N. schrieb:
> int read_val(int length) {
>   char input[length];

Das geht erst ab C99.  Ab C11 ist der Support für VLAs nur noch 
optional.

>   inputse(input, length);
>   return atoi(input);
> }

Evtl. alloca versuchen

https://linux.die.net/man/3/alloca

Bastian N. schrieb:
> // ANSII standard
> extern int strlen(far char* px);
> ...

"far" ist ANSI.  Joooo alles klar!

[Bastian N. (Firma: Privat) (seal)]

Hallo Johann,

vielen Dank für den Tipp mit alloca. Leider hat der Wickenhäuser das 
nicht dabei. Was für ein ...

17.04.2004  21:25             2.421 89C51RD2.H
28.08.2003  00:23             2.611 ADuC812.def
29.02.2004  18:41             5.190 ADuC812.H
16.01.2003  16:11             7.531 ADuC816.def
29.02.2004  18:48             4.464 ADuC816.h
16.01.2003  16:13             7.661 ADuC824.def
29.02.2004  18:48             4.565 ADuC824.h
20.02.2005  18:42             8.823 at89c51cc03.def
09.12.2005  16:25             9.561 at89c51cc03.h
31.10.2002  22:45               274 bin_safe.h
17.04.2005  21:49             9.305 C8051F000.def
18.04.2005  00:05            14.523 c8051F000.h
17.04.2005  22:42            10.254 C8051F020.def
18.04.2005  00:03            16.387 c8051F020.h
17.04.2005  21:54            22.178 C8051F040.def
18.04.2005  00:03            22.708 c8051F040.h
17.04.2005  20:12            19.079 C8051F060.def
18.04.2005  00:03            20.586 c8051F060.h
17.04.2005  21:55            17.180 C8051F120.def
18.04.2005  00:03            18.114 c8051F120.h
17.04.2005  22:04             6.901 C8051F200.def
18.04.2005  00:04            10.590 c8051F200.h
17.04.2005  21:57             7.388 C8051F300.def
18.04.2005  00:04            12.111 c8051F300.h
17.04.2005  21:58            15.206 C8051F310.def
18.04.2005  00:04            16.042 c8051F310.h
17.04.2005  21:59            15.210 C8051F320.def
18.04.2005  00:04            16.677 c8051F320.h
17.04.2005  22:01             9.277 C8051F330.def
18.04.2005  00:05             9.965 c8051F330.h
17.04.2005  22:02             9.910 C8051F350.def
18.04.2005  00:05            10.654 c8051F350.h
10.11.2006  19:25            10.615 cc2510.h
15.07.2002  12:10               219 ctype.h
24.02.2003  13:04               865 irq52.h
24.02.2003  13:10               372 kar.h
22.01.2007  22:14             3.551 lpc922.h
28.01.2003  22:04             1.002 math.h
18.03.2006  14:25             1.066 MPC89E52.def
18.03.2006  00:42             1.081 MPC89E52.h
17.04.2005  22:04             1.437 p03bits.h
13.02.2003  22:41             3.435 reg1210.def
24.02.2003  13:05             5.354 Reg1210.h
06.08.2003  15:08             3.660 reg1211.def
10.10.2003  13:09             5.555 REG1211.h
27.09.2002  19:00             2.733 reg51.def
07.05.2003  00:18             3.288 reg51.h
21.05.2003  12:49               890 reg52.def
14.07.2002  21:21               837 reg52.h
14.07.2002  21:16             1.538 reg535.def
14.07.2002  21:22             1.437 reg535.h
29.09.2003  00:09             3.996 reg552.def
29.09.2003  00:09             3.343 reg552.h
13.02.2003  22:40               967 rom1210.h
12.05.2002  18:31               699 stdarg.h
04.05.2003  19:41             1.274 stdio.h
30.07.2002  21:29               496 string.h
19.06.2005  13:02               527 sys51.h

Das ist alles was diese "tolle" Entwicklungsumgebung/Compiler bietet.
Oh man, was für ein Schmu...

... wie kann man nur sowas als Studienvorlage nehmen?

Frust.

[Johann L. (gjlayde)]

Bastian N. schrieb:
> Das ist alles was diese "tolle" Entwicklungsumgebung/Compiler bietet.
> Oh man, was für ein Schmu...

Nett.  Einfach den Device-Support zu den Standard-Headern geklatscht, 
die übrigens unvollständig sind.  Fehlt zum Beispiel stdlib.h.  Und 
C99-Header wie stdbool.h, stdint.t und inttypes.h sowieso.

> ... wie kann man nur sowas als Studienvorlage nehmen?

Vielleicht weil's kostenlos ist?

Du kannst in den sauren Apfel beißen und malloc bemühen, falls das 
verfügbar ist, ist aber auf so nem Hänfling i.d.R. Overkill.

Oder length statisch nach oben abschätzen.

Oder falls das nicht geht, eine "vernünftige" Obergrenze für length 
statisch festlegen, und wenn length zu groß ist nen Fehler ausgeben.

[Frank K. (fchk)]

Bastian N. schrieb:

int read_val(const int* length) 
{
  int rv=-1;
  char* input;
  input=malloc(length);
  if (input)
  {  
    inputse(input, length);
    rv=atoi(input);
    free(input);
  }
  return rv;
}

So ist es in richtigem C gedacht.

fchk

[Johann L. (gjlayde)]

Frank K. schrieb:
> Bastian N. schrieb:
>

> int read_val(const int* length)
> {
>   int rv=-1;
>   char* input;
>   input=malloc(length);
>   if (input)
>   {
>     inputse(input, length);
>     rv=atoi(input);
>     free(input);
>   }
>   return rv;
> }
>

>
> So ist es in richtigem C gedacht.


Naja, da bekäne malloc ein size_t, nicht einen const int*.

[R. F. (rfr)]

Wer malloc hat, kann es nutzen. Vermutlich hat er aber nicht, auf 
Controllern ist typischerweise kein OS.

Robert

[Bastian N. (Firma: Privat) (seal)]

@Johann
Du ich hab da gar nix geklatscht. Das ist alles aus dem /include Ordner 
von Wickenhäuser nix verändert, einfach ein dir/ls auf das Verzeichnis.

Habe jetzt nochmal weiter rumgekruschtelt:

 Verzeichnis von p:\Programme\uC51\lib\lib_c

16.05.2017  16:56    <DIR>          .
16.05.2017  16:56    <DIR>          ..
14.07.2002  00:04             1.596 atof.c
14.07.2002  20:53               643 atoi.c
14.07.2002  00:46               669 atol.c
16.07.2002  23:15               975 bmove.c
15.07.2002  12:08               375 ctype.c
11.02.2006  12:47            21.114 doprnt.c
14.07.2002  00:05             1.052 inputse.c
30.07.2002  21:39               415 memcmp.c
24.07.2002  16:26               700 printf.c
13.07.2002  20:27               551 puts.c
04.05.2003  19:53             1.296 rand.c
08.01.2003  19:42               920 sprintf.c
07.06.2004  19:39             8.222 startup.c
30.07.2002  21:39               389 strcmp.c
16.07.2002  17:48               296 strcpy.c
16.07.2002  01:04               274 strlen.c

Das ist aber auch wirklich alles.
Klar ist es kostenlos - also bis 8kb, aber leider auch sehr beschnitten, 
oder?


@Frank
Vielen Dank dafür :D - ist echt schön gelößt. Leider wird das so bei 
Wickenhäuser nicht unterstützt. Aber trotzdem vielen Dank für *So geht 
es richtig*.

[Johann L. (gjlayde)]

Bastian N. schrieb:
> @Johann
> Du ich hab da gar nix geklatscht. Das ist alles aus dem /include Ordner
> von Wickenhäuser nix verändert, einfach ein dir/ls auf das Verzeichnis.

Hab ich so vermutet :-/

> Klar ist es kostenlos

Hab ich einfach nur geraten, nach dem Motto: die werden dafür doch nicht 
etwa noch...

> @Frank
> Vielen Dank dafür :D - ist echt schön gelößt. Leider wird das so bei
> Wickenhäuser nicht unterstützt.

malloc könntest du immerhin noch selbst dazuklöppeln — im gegensatz zu 
alloca.  Bei letzterem wüsste ich noch nicht mal bei GCC + InlineASM, 
wie man das unterstützen könnte.

Aber selbst auf Bare Metal ist malloc sehr aufwändig, weil 
(Listene)verwaltung für die allokierten / freien  Blöcke gebraucht wird. 
Die wiederum frisst am Programmspeicher und hat auch einen merlichen 
Overhead an RAM-Verbrauch.

[R. F. (rfr)]

Bei einem 8051 ist der Speicher recht überschaubar, ich würde das mit 
(im ROM liegenden) Zeigern und Bereichen fester Grösse machen.

Robert

[Bastian N. (Firma: Privat) (seal)]

Johann L. schrieb:
> Bastian N. schrieb:
>> @Johann
>> Du ich hab da gar nix geklatscht. Das ist alles aus dem /include Ordner
>> von Wickenhäuser nix verändert, einfach ein dir/ls auf das Verzeichnis.
>
> Hab ich so vermutet :-/

Kann man wohl nix machen :-C

>> Klar ist es kostenlos
>
> Hab ich einfach nur geraten, nach dem Motto: die werden dafür doch nicht
> etwa noch...
>
Das Schlimmste ist, dass Wickenhäuser nicht mehr erreichbar ist, bzw. 
das Ding überhaupt nicht mehr "supportet" wird.

>> @Frank
>> Vielen Dank dafür :D - ist echt schön gelößt. Leider wird das so bei
>> Wickenhäuser nicht unterstützt.
>
> malloc könntest du immerhin noch selbst dazuklöppeln — im gegensatz zu
> alloca.  Bei letzterem wüsste ich noch nicht mal bei GCC + InlineASM,
> wie man das unterstützen könnte.
Ergo, wohl unmöglich...

> Aber selbst auf Bare Metal ist malloc sehr aufwändig, weil
> (Listene)verwaltung für die allokierten / freien  Blöcke gebraucht wird.
> Die wiederum frisst am Programmspeicher und hat auch einen merlichen
> Overhead an RAM-Verbrauch.
Habe C/C++ nur in der Ausbildung zum FI/AW gehabt und da ging es um 
andere Dinge. Habe dann lange in Java entwickelt, aber will jetzt zu 
neuen Ufern...



R. F. schrieb:
> Bei einem 8051 ist der Speicher recht überschaubar, ich würde das mit
> (im ROM liegenden) Zeigern und Bereichen fester Grösse machen.
>
> Robert
Also im Prinzip wie mit dem define-Lösung, wie von Baldrian 
vorgeschlagen?
Oder was meinst du mit:

> (im ROM liegenden) Zeigern

[Johann L. (gjlayde)]

Bastian N. schrieb:
> Johann L. schrieb:
>> malloc könntest du immerhin noch selbst dazuklöppeln — im gegensatz zu
>> alloca.  Bei letzterem wüsste ich noch nicht mal bei GCC + InlineASM,
>> wie man das unterstützen könnte.
> Ergo, wohl unmöglich...

Wenn es nur zu Lernzwecken ist, wird es ja nicht wirklich "gebraucht". 
Du weisst ja, wie man es mit Standard-C umsetzen kann.

Fall es sich um ein ernsthaftes Projekt handelt — bei der C-Umgebung 
eher unwahrschenilich — UND ein Array mit erst zur Laufzeit bekannter 
Größe unabdingbar ist, dann wäre eine mögliche Implementation qua 
Assembler-Wrapper, der ein Array entsprechender Große auf dem Stack 
anlegt, samt length an die Zielfunktion übergibt und nach deren 
Ausführung wieder alles aufräumt.

Auf AVR + avr-gcc hab ich eine ähnliche Situation mal folgendermaßen 
gelöst.  Dabei erfüllte der benötigte Speicher die Eigenschaften von 
alloca, d.h. Allokation und Freigabe erfolgen immer korrekt 
geschachtelt, und zudem wurde im Programm kein malloc etc. verwendet. 
Auf den statisch belegten Speicher folgt ein freier Bereich bis zum 
Stack, und auf den Anfang dieses Bereichs definiert der Linker ein 
Symbol __heap_start, das man per C zugreifen kann.
 
Lokalen Speicher kann man sich dann folgendermaßen besorgen, um in 
deinem Code zu bleibem:
 

int read_val (size_t length)
{
  char *input = my_memory;
  my_memory += length;
  inputse (input, length);
  int ret = atoi (input)
  my_memory -= length;
  return ret;
}

 
In diesem Fall ist my_memory im Static Storage und wird vom Startup-Code 
initialisiert:
 

extern char __heap_start[]; // Defined in default linker script
char *my_memory = __heap_start;

[Markus F. (mfro)]

Natürlich wäre es schön, wenn ein in der Lehre verwendeter Compiler 
aktuellem Standard entsprechen würde. Noch schöner natürlich, wenn das 
nicht gerade auf nahezu 40 Jahre alten µC-Konzepten (8051) passieren 
würde.

Aber Rummeckern bringt nichts. VLAs sind eine recht neumodische 
Erweiterung des Standards und so zu tun, als ob man ohne nichts 
Vernünftiges zustande brächte, ist Blödsinn: Generationen von 
Entwicklern sind ohne VLAs ausgekommen und haben trotzdem brauchbare 
Programme geschrieben. Ich würde schätzen, daß deutlich weniger als 10% 
des Codes, der aktuell gerade auf µC ausgeführt wird, überhaupt VLAs 
enthält. Man darf sich auch fragen, ob das auf so schwachbrüstigem Gerät 
ohne entsprechende Runtime-Unterstützung überhaupt sinnvoll ist (was 
passiert, wenn das VLA keinen Platz mehr hat?).

Dein initialer Post verrät, daß Du - mit Verlaub - über C noch eine 
Menge zu lernen hast, bevor Du ein derart scharfes Messer wie VLAs 
sinnvoll einsetzen kannst.

[Rolf M. (rmagnus)]

Markus F. schrieb:
> Natürlich wäre es schön, wenn ein in der Lehre verwendeter Compiler
> aktuellem Standard entsprechen würde. Noch schöner natürlich, wenn das
> nicht gerade auf nahezu 40 Jahre alten µC-Konzepten (8051) passieren
> würde.

Das kommt sicher auch durch den einen oder anderen Professor, der das 
"früher" eben so benutzt hat und auch nach 30 Jahren keine Lust hat, 
sein ganzes Lehrmaterial mal auf was neues umzustellen. Andererseits 
sind solche veralteten Sachen auch in der Industrie durchaus 
anzutreffen.

> Aber Rummeckern bringt nichts. VLAs sind eine recht neumodische
> Erweiterung des Standards

Genau... seit 18 Jahren sind sie fester Bestandteil davon - bessere 
Compiler haben sie schon Jahre vorher unterstützt. Das würde ich nun 
gerade im Bereich Software-Entwicklung nicht wirklich nicht als "recht 
neumodisch" bezeichnen.

> und so zu tun, als ob man ohne nichts Vernünftiges zustande brächte, ist
> Blödsinn: Generationen von Entwicklern sind ohne VLAs ausgekommen und
> haben trotzdem brauchbare Programme geschrieben.

Naja, man kann sich immer auf dem Status Quo ausruhen und sagen, dass es 
ja bisher ja auch ohne die neuen Features ging. So entwickelt sich aber 
nix weiter.

> Ich würde schätzen, daß deutlich weniger als 10% des Codes, der aktuell
> gerade auf µC ausgeführt wird, überhaupt VLAs enthält. Man darf sich auch
> fragen, ob das auf so schwachbrüstigem Gerät ohne entsprechende Runtime-
> Unterstützung überhaupt sinnvoll ist (was passiert, wenn das VLA keinen
> Platz mehr hat?).

Das ist aber keine spezielle Eigenart von VLAs. Daten mit dynamischer 
Größe sind grundsätzlich ein Problem bei µCs mit so wenig Speicher.

Bastian N. schrieb:
> Also bei Wickenhäuser steht folgendes:
> ANSI C compiler
>  Full support for the ANSI C language. NOT a reduced
> subset of C or extended K&R C.

Spannend... da es ja erstens offenbar kein vollständiges ANSI C umsetzt 
und zweitens ANSI C schon lange offiziell nicht mehr existiert.

[Rufus Τ. F. (rufus)]

Bastian N. schrieb:
> Also ANSI C?

Als "ANSI-C" wird üblicherweise C89 bezeichnet. Alles, was neuere 
Standards kennt, verwendet die jeweilige Standardbezeichnung (also C99, 
C11 etc.).

C89 war der erste (und sehr große) Fortschritt gegenüber dem kruden 
K&R-C.

[Markus F. (mfro)]

Rolf M. schrieb:
> Das ist aber keine spezielle Eigenart von VLAs. Daten mit dynamischer
> Größe sind grundsätzlich ein Problem bei µCs mit so wenig Speicher.

Eben. Das scheint der TO aber noch nicht erkannt zu haben.

Im Gegensatz zu "echter" dynamischer Speicherverwaltung erlauben VLAs 
keine Fehlerbehandlung. Dafür gibt es keine Sprachunterstützung. Wenn 
man's merkt, ist's längst zu spät.

Ich habe für mich bislang nur eine einzige sinnvolle 
Anwendungsmöglichkeit für VLAs gefunden, ohne Tretminen ins Programm zu 
packen, die einem garantiert irgendwann um die Ohren fliegen:

mehrdimensionale Arrays, bei denen zwar die Gesamtgröße zum 
Compile-Zeitpunkt bekannt ist, nicht aber die Verteilung auf die 
einzelnen Dimensionen. Das artet ohne VLAs zu reichlich konfusem Code 
aus und läßt sich mit sehr viel eleganter schreiben. Allerdings braucht 
man (ich) das eher selten. Wirklich "dynamisch" ist's auch nicht, wenn 
man's wasserdicht machen will.

[Yalu X. (yalu) (Moderator)]

Da du den eingelesenen String mit atoi() in eine Integer-Zahl
konvertierst, ist length doch sicher begrenzt, bspw. auf 6 (Vorzeichen
und die maximal 5 Ziffern einer 16-Bit-Zahl). Somit könntest du die
Größe von input[] konstant auf 7 festlegen. In deinem Code hast du
übrigens bei der Dimensionierung von input[] die Stringende-Null nicht
berücksichtigt.

Oder du verzichtest auf den Stringpuffer, liest die Eingabe stattdessen
zeichenweise und programmierst du Konvertierung selber. Im einfachsten
Fall (für positive Zahlen) sind das nur ganz wenige Codezeilen:

unsigned int read_val(int length) {
  unsigned int val = 0;

  while(length--)
    val = 10 * val + read_char() - '0';

  return val;
}

Ggf. kommen noch zusätzliche Abfragen für die Vorzeichenbehandlung und
die Prüfung, ob die eingelesenen Zeichen tatsächlich Ziffern sind,
hinzu.

[Markus F. (mfro)]

Markus F. schrieb:
> Rolf M. schrieb:
>> Das ist aber keine spezielle Eigenart von VLAs. Daten mit dynamischer
>> Größe sind grundsätzlich ein Problem bei µCs mit so wenig Speicher.
>
> Eben. Das scheint der TO aber noch nicht erkannt zu haben.

Im Übrigen - wenn ich das noch ergänzen darf - hat das Fehlerpotential 
mit der Speichergröße überhaupt nichts zu tun, sondern eher mit der 
Runtime-Unterstützung bzw. dem (Nicht-) Vorhandenseins eines 
Betriebssystems.

Die Vorstellung, man könne mit dynamischer Speicherverwaltung auf einem 
Multi-TB-Server "schlampiger" umgehen, als auf einem µC, bloß weil "so 
viel davon da ist", ist zwar weit verbreitet, aber irrig.

[Rolf M. (rmagnus)]

Markus F. schrieb:
> Im Übrigen - wenn ich das noch ergänzen darf - hat das Fehlerpotential
> mit der Speichergröße überhaupt nichts zu tun, sondern eher mit der
> Runtime-Unterstützung bzw. dem (Nicht-) Vorhandenseins eines
> Betriebssystems.
>
> Die Vorstellung, man könne mit dynamischer Speicherverwaltung auf einem
> Multi-TB-Server "schlampiger" umgehen, als auf einem µC, bloß weil "so
> viel davon da ist", ist zwar weit verbreitet, aber irrig.

Keiner hat gesagt, man solle auf dem Server schlampig mit dem Speicher 
umgehen.
Auf dem µC ist der Speicher viel früher zu Ende als auf dem PC, und da 
sprechen wir nicht von einem Faktor von 2 oder so. Ich programmiere für 
beide, und mein PC hat 64 Millionen mal soviel Speicher wie der µC, den 
ich programmiere. Dass man dann mit dem Speicher natürlich ganz anders 
umgeht, ist ja logisch. Das hat aber mit Schlampigkeit nichts zu tun. Es 
ist eher so, dass man auf dem µC sehr viel statisch macht, da schon zwei 
dynamisches Strings den Speicher sehr schnell komplett füllen und man 
dann Platz für absolut gar nichts anderes mehr hat. Auf dem PC ist 
dagegen statischer Speicher in der Regel eher "pfui", weil er zu 
Einschränkungen führt. So gut wie alles wird dort mit dynamischem 
Speicher gemacht. Ist das deswegen automatisch "schlampig"?

[Markus F. (mfro)]

Rolf M. schrieb:
> Auf dem PC ist
> dagegen statischer Speicher in der Regel eher "pfui", weil er zu
> Einschränkungen führt. So gut wie alles wird dort mit dynamischem
> Speicher gemacht. Ist das deswegen automatisch "schlampig"?

Ich habe keineswegs behauptet, daß dynamischer Speicher immer schlampig 
wäre, sondern das im Kontext dieses Freds und von VLAs verstanden. Und 
die hat der TO beispielsweise in seinem initialen Post mit einem 
ungeprüften Eingangswert verwendet. Da könnte auch mal SIZE_MAX 
drinstehen.

Ja, das nenne ich schlampig.

Jetzt könnte man noch drüber philosophieren, was - wenn dieser 
Eingangswert  geprüft werden soll - wohl ein sinnvoller Wert wäre, gegen 
den man da prüft. Ich wüsste nicht, wie man die Frage beantworten 
sollte, außer "gegen irgendeinen Wert, der beim Testen nicht zu Fehlern 
geführt hat". Den kann ich dann auch gleich fest hinschreiben und 
brauche VLAs gar nicht (außer für meinen einen o.g. - seltenen - 
Anwendungsfall).

[Peter D. (peda)]

Bastian N. schrieb:
> Hmm, das habe ich mir auch schon überlegt. Leider geht so die
> Flexibilität verloren.

Du gewinnst damit nichts. Du mußt eh Platz für den Worst-Case auf dem 
Stack frei haben.
Der C51 kann ja kein Multitasking, d.h. keine andere Task kann den 
freien Speicher nutzen.

[Rufus Τ. F. (rufus)]

Peter D. schrieb:
> Der C51 kann ja kein Multitasking, d.h. keine andere Task kann den
> freien Speicher nutzen.

Aber ein Interrupt kann 'reinrauschen, und der zugehörige 
Interrupthandler braucht Stack.

[Peter D. (peda)]

Rufus Τ. F. schrieb:
> Aber ein Interrupt kann 'reinrauschen, und der zugehörige
> Interrupthandler braucht Stack.

Interrupts muß man doch immer berücksichtigen. Die Atmel 8051 können 
sogar bis zu 4 Interrupts schachteln, wenn man es erlaubt.

[S. R. (svenska)]

Rolf M. schrieb:
> Das kommt sicher auch durch den einen oder anderen Professor, der das
> "früher" eben so benutzt hat und auch nach 30 Jahren keine Lust hat,
> sein ganzes Lehrmaterial mal auf was neues umzustellen.

Würde er dafür bezahlt werden? Vermutlich nicht, denn Professoren sind 
heutzutage mehr damit beschäftigt, Anträge zu schreiben und Gelder 
einzuwerben.

Für neue Kurse kann man gelegentlich Geld aus dem System leiern, aber um 
einen Kurs mal inhaltlich komplett auf den neuen Stand zu bringen? Wer 
soll das denn machen? Der HiWi?

>> Aber Rummeckern bringt nichts. VLAs sind eine recht neumodische
>> Erweiterung des Standards
> Genau... seit 18 Jahren sind sie fester Bestandteil davon - bessere
> Compiler haben sie schon Jahre vorher unterstützt.

Gib mir mal bitte eine Liste von Compilern, die C99 vollständig 
unterstützen. Außer gcc und llvm fällt mir da nämlich keiner ein (Visual 
C++ tut es jedenfalls nicht).

Wieviele Compiler mit teilweiser C99-Kompatiblität können 8051? SDCC ist 
da gut dabei, kann aber an sich nichtmal C89 vollständig.

> Das würde ich nun gerade im Bereich Software-Entwicklung
> nicht wirklich nicht als "recht neumodisch" bezeichnen.

Und? Davon kannst du dir auch nichts kaufen.

> Spannend... da es ja erstens offenbar kein vollständiges ANSI C umsetzt
> und zweitens ANSI C schon lange offiziell nicht mehr existiert.

ANSI C == C89.

[Bastian N. (Firma: Privat) (seal)]

Markus F. schrieb:
> Dein initialer Post verrät, daß Du - mit Verlaub - über C noch eine
> Menge zu lernen hast
Auch ohne Verlaub hast du 100% recht. C ist halt doch was gaanz anderes 
wie C-Sharp/JAVA ;-)

Rolf M. schrieb:
> Bastian N. schrieb:
>> Also bei Wickenhäuser steht folgendes:
>> ANSI C compiler
>>  Full support for the ANSI C language. NOT a reduced
>> subset of C or extended K&R C.
>
> Spannend... da es ja erstens offenbar kein vollständiges ANSI C umsetzt
> und zweitens ANSI C schon lange offiziell nicht mehr existiert.
Ja Wickenhäuser ist komisch. Hab bisher nix gutes über ihn/die IDE 
gelesen - ausser das kostenlos bis 8kb...



Yalu X. schrieb:
> Da du den eingelesenen String mit atoi() in eine Integer-Zahl
> konvertierst, ist length doch sicher begrenzt, bspw. auf 6 (Vorzeichen
> und die maximal 5 Ziffern einer 16-Bit-Zahl). Somit könntest du die
> Größe von input[] konstant auf 7 festlegen. In deinem Code hast du
> übrigens bei der Dimensionierung von input[] die Stringende-Null nicht
> berücksichtigt.
Ist mir am Wochenende auch aufgefallen. Prinzipiell würde aber früher 
oder später bei mir die Frage mit den dynamischen Arrays aufkommen. Da 
ich es gelernt habe, mein Code möglichst flexibel und wiederverwertbar 
zu halten.
C hatte ich, wie schon geschrieben, nur in der Ausbildung gemacht - was 
aber schon länger als 10 Jahre her ist.

> > Oder du verzichtest auf den Stringpuffer, liest die Eingabe stattdessen
> zeichenweise und programmierst du Konvertierung selber. Im einfachsten
> Fall (für positive Zahlen) sind das nur ganz wenige Codezeilen:
>
> unsigned int read_val(int length) {
>   unsigned int val = 0;
>
>   while(length--)
>     val = 10 * val + read_char() - '0';
>
>   return val;
> }
>
> Ggf. kommen noch zusätzliche Abfragen für die Vorzeichenbehandlung und
> die Prüfung, ob die eingelesenen Zeichen tatsächlich Ziffern sind,
> hinzu.
DAS IST GENAU DIE RICHTIGE LÖSUNG! VIELEN DANK DAFÜR!!

S. R. schrieb:
> Rolf M. schrieb:
>> Das kommt sicher auch durch den einen oder anderen Professor, der das
>> "früher" eben so benutzt hat und auch nach 30 Jahren keine Lust hat,
>> sein ganzes Lehrmaterial mal auf was neues umzustellen.
>
> Würde er dafür bezahlt werden? Vermutlich nicht, denn Professoren sind
> heutzutage mehr damit beschäftigt, Anträge zu schreiben und Gelder
> einzuwerben.
Anscheinend schon. Als der Prof, von dem die Lehrhefte (ursprünglich für 
Elektor) geschrieben hat (und damit Wickenhäuser vorgegeben hat), heißt 
Bernd v. Berg.

> Wieviele Compiler mit teilweiser C99-Kompatiblität können 8051? SDCC ist
> da gut dabei, kann aber an sich nichtmal C89 vollständig.
Den SDCC würde ich gerne mal benutzen, benutzt aber einen anderen Aufbau 
der Header Files (für die SFR etc.) als der Wickenhäuser und sind somit 
inkompatibel. Finde im Netzt auch nix verwertbares.


MfG
Basti

Und vielen Dank an alle für eure Hilfe :)

[Bastian N. (Firma: Privat) (seal)]

Yalu X. schrieb:
> unsigned int read_val(int length) {
>   unsigned int val = 0;
>
>   while(length--)
>     val = 10 * val + read_char() - '0';
>
>   return val;
> }

Achso read_char gibt es in C nicht. Bin sicher es ist getchar() 
gemeint...

[Jörg W. (dl8dtl) (Moderator)]

S. R. schrieb:
> Gib mir mal bitte eine Liste von Compilern, die C99 vollständig
> unterstützen.

IAR.  Sogar mit vollständiger Bibliothek (kein Wunder, die hat man
von P. J. Plauger zugekauft, der im Normungsgremium sitzt ;).

[S. R. (svenska)]

Jörg W. schrieb:
> IAR [kann C99]

Hmm, von dem nutzen wir nur den Assembler in der Uni. Aber gut zu 
wissen, dass der C99 kann - kann der auch C11 (und für alle 
Architekturen)?

[Jörg W. (dl8dtl) (Moderator)]

S. R. schrieb:
> kann der auch C11

Weiß ich nicht, habe ihn lange nicht mehr in den Fingern gehabt.

> (und für alle Architekturen)

Ich würde keinen Grund sehen, warum es, sofern vorhanden, dann nicht
für alle Architekturen vorhanden sein sollte.  Der Compiler selbst ist
ja immer generisch, die architekturabhängigen Teile sind erst so weit
hinten, dass sie vom Frontend nur noch wenig beeinflusst sind.

[Ohmar (Gast)]

wickenhaeuser.de, selten so 'ne schlechte Website gesehen.

[Olaf B. (Firma: OBUP) (obrecht)]

Bastian N. schrieb:
> Das Schlimmste ist, dass Wickenhäuser nicht mehr erreichbar ist, bzw.
> das Ding überhaupt nicht mehr "supportet" wird.

Probier doch http://www.wickenhaeuser.de/_index.html
Sollte noch funzen. :-)

mfg

Olaf

[Johann L. (gjlayde)]

Jörg W. schrieb:
> S. R. schrieb:
>> Gib mir mal bitte eine Liste von Compilern, die C99 vollständig
>> unterstützen.
>
> IAR.  Sogar mit vollständiger Bibliothek (kein Wunder, die hat man
> von P. J. Plauger zugekauft, der im Normungsgremium sitzt ;)

Oje Dinkum...

[Yalu X. (yalu) (Moderator)]

Bastian N. schrieb:
> Achso read_char gibt es in C nicht. Bin sicher es ist getchar()
> gemeint...

Im Original wird der String mit inputse() gelesen, was auch nicht in der
C-Bibliothek vorhanden ist. Da ich nicht wusste, von welcher Datenquelle
inputse() den String liest, habe ich als generischen Platzhalter einfach
mal read_char genommen. Du kannst ihn ersetzen durch getchar, fgetc oder
irgendetwas anderes, das das jeweils nächste Zeichen aus der Datenquelle
liefert.

[Rolf M. (rmagnus)]

S. R. schrieb:
> Rolf M. schrieb:
>> Das kommt sicher auch durch den einen oder anderen Professor, der das
>> "früher" eben so benutzt hat und auch nach 30 Jahren keine Lust hat,
>> sein ganzes Lehrmaterial mal auf was neues umzustellen.
>
> Würde er dafür bezahlt werden?

Er wird eigentlich dafür bezahlt, aktuelles Wissen zu vermitteln. Und 
wenn man nicht 30 Jahre gar nichts tut, sondern Schritt für Schritt das 
ganze auf dem Laufenden hält, ist auch der Aufwand nicht ganz so riesig.

>>> Aber Rummeckern bringt nichts. VLAs sind eine recht neumodische
>>> Erweiterung des Standards
>> Genau... seit 18 Jahren sind sie fester Bestandteil davon - bessere
>> Compiler haben sie schon Jahre vorher unterstützt.
>
> Gib mir mal bitte eine Liste von Compilern, die C99 vollständig
> unterstützen.

Die Unfähigkeit (oder auch der Unwillen) vieler Compilerhersteller hat 
erstmal ja nichts damit zu tun, dass etwas, das seit 18 Jahren 
eigentlich vorgeschrieben ist, "neumodisch" wäre. Aber die 
Compilerhersteller, die sich immer noch auf C89 ausruhen, sehen das wohl 
so und wollen dieses "neumodische Gelumpe" nicht haben. Die verweigern 
sich wahrscheinlich auch dem Internet und haben statt Fernseher nur ein 
Röhrenradio. ;-)

>> Das würde ich nun gerade im Bereich Software-Entwicklung
>> nicht wirklich nicht als "recht neumodisch" bezeichnen.
>
> Und? Davon kannst du dir auch nichts kaufen.

Hab ich ja auch nicht behauptet.

>> Spannend... da es ja erstens offenbar kein vollständiges ANSI C umsetzt
>> und zweitens ANSI C schon lange offiziell nicht mehr existiert.
>
> ANSI C == C89.

Ja, C wird aber nicht mehr von ANSI, sondern von der ISO genormt, und 
auch dort wird mit Erscheinen jeder neuen Version die vorhergehende für 
ungültig erklärt.

[S. R. (svenska)]

Rolf M. schrieb:
> Er wird eigentlich dafür bezahlt, aktuelles Wissen zu vermitteln. Und
> wenn man nicht 30 Jahre gar nichts tut, sondern Schritt für Schritt das
> ganze auf dem Laufenden hält, ist auch der Aufwand nicht ganz so riesig.

Tja, wenn in diesem Satz das "eigentlich" nicht wäre...

Ich sehe bei uns z.B., dass die Stunden für Lehre systematisch 
zusammengestrichen werden, und man schon jetzt mehr Zeit reinstecken 
muss, als man angerechnet bekommt. Updates für die Kurse sind da nicht 
eingerechnet, Vorbereitung auch nicht. Betreuung von Arbeiten macht man 
aus altruistischen Gründen, oder nur minimal.

Dass da am Ende nur Dienst nach Vorschrift bei rauskommt, ist 
nebensächlich. Dafür wird die Administration aber zunehmend gleichmäßig 
auf alle Schultern verteilt. Hier 1% mehr Papierkram, da eine 
Wochenstunde mehr Meetings, ... und am Ende bleibt für die eigentliche 
Arbeit keine Zeit übrig.

>> Gib mir mal bitte eine Liste von Compilern, die C99 vollständig
>> unterstützen.
> Die Unfähigkeit (oder auch der Unwillen) vieler Compilerhersteller hat
> erstmal ja nichts damit zu tun, dass etwas, das seit 18 Jahren
> eigentlich vorgeschrieben ist, "neumodisch" wäre.

Ja, aber sich hinzustellen, dass "das jetzt seit 18 Jahren im Standard 
wäre", wenn die Tools das nicht unterstützen, bringt halt auch nichts.

Ich habe als Kind auch Standards geschrieben, die nie jemand 
implementiert hat. Da kann ich mich auch nicht drauf berufen, obwohl die 
auch alt sind. ;-)

>>> Spannend... da es ja erstens offenbar kein vollständiges ANSI C umsetzt
>>> und zweitens ANSI C schon lange offiziell nicht mehr existiert.
>>
>> ANSI C == C89.
>
> Ja, C wird aber nicht mehr von ANSI, sondern von der ISO genormt, und
> auch dort wird mit Erscheinen jeder neuen Version die vorhergehende für
> ungültig erklärt.

Das bringt's natürlich... bleibt das gleiche Argument: Nur, weil jemand 
es in einen Standard geschrieben hat, ist es noch lange nicht 
implementiert, getestet, zertifiziert oder auch nur funktionsfähig.

[Jörg W. (dl8dtl) (Moderator)]

S. R. schrieb:
> Ja, aber sich hinzustellen, dass "das jetzt seit 18 Jahren im Standard
> wäre", wenn die Tools das nicht unterstützen, bringt halt auch nichts.

Man muss sich ja kein Beispiel an Microsoft nehmen.

Compiler, die neuere Standardversionen unterstützen, wurden ja durchaus
schon genannt.  Gerade im universitären Umfeld gibt es doch gar keinen
Grund, nicht auf GCC oder LLVM / Clang zurückzugreifen.  Auch einen
8051 kann man getrost als auf den Müllhaufen der Geschichte gehörend
einsortieren für die Lehre.  Nimmt man einen kleinen ARM, dann ist der
GCC völlig gleichwertig mit kommerziellen Compilern, man muss dann nur
noch eine passende IDE suchen, schon hat man ein zeitgemäßes Konzept
für eine Ausbildung im Bereich der Mikrocontroller.  Irgendwelchen
Käse mit Speichersegmentierung oder Zeropages braucht man als Student
wirklich nicht mehr für den Einstieg zu lernen, dafür darf man sich
mit Clock Trees herumschlagen und warum eben nicht alle Peripherals
standardmäßig gleich mit dem Takt mehr mitklappern und Strom ziehen.

[Yalu X. (yalu) (Moderator)]

Rolf M. schrieb:
> Aber die Compilerhersteller, die sich immer noch auf C89 ausruhen,
> sehen das wohl so und wollen dieses "neumodische Gelumpe" nicht haben.
> Die verweigern sich wahrscheinlich auch dem Internet und haben statt
> Fernseher nur ein Röhrenradio. ;-)

Die Compilerhersteller können sich deswegen ausruhen, weil von ihren
Kunden kaum jemand nach C99 oder gar C11 fragt. So ist in der
Autoindustrie immer noch C89 der Standard. MISRA berücksichtigt C99
(nicht C11) auch erst seit 2013, aber das ist immerhin schon einmal ein
erster Schritt. Bei der Geschwindigkeit, mit der die Mühlen in
Großkonzernen mahlen, wird es sicher noch ein paar Jahre dauern, bis
sich C99 durchsetzt.

Dennoch erfüllen inzwischen die meisten C-Compiler die C99-Norm. Und
eins der tollen neuen Features erfreut die Anwender ganz besonders:
Nämlich die Kommandzeilenoption zur Aktivierung des C89-Modus :)