Sprache C - > long oder besser immer long long

Walter K. schrieb:
> wäre dann long long statt long für die Zukunft sicherer?

Warum machst Du sowas? Der Code ist doch kompletter Unsinn?!? Den kann 
man komplett ohne irgendwelche "long"-Casts portabel formulieren, ohne 
die Bitbreite des Prozessors zu kennen.

Walter K. schrieb:
> nachfolgender Code dürfte ja zukünftig z.B. auf 128Bit Maschinen gegen
> die Wand laufen:

Schreibe einfach:

1

#include <stdio.h>

2

#include <stdlib.h>

3

#include <string.h>

4

5

int main ()

6

{

7

    char string[] = "beliebiger Text";

8

    char * ptr;

9

10

    ptr = malloc(strlen(string) + 1);

11

    snprintf(ptr, strlen(string) + 1, "%s", string);

12

    printf("%s\n", ptr);

13

14

    return 0;

15

}

Funktioniert mit Bitbreiten von 8, 16, 32, 64 und 128. Wenn die ersten 
Maschinen mit 256 Bit rauskommen, kannst Du Dich nochmal melden.

P.S.
Das obige kann man auch noch um einiges performanter machen. Aber das 
ist jetzt hier nicht die Aufgabe gewesen ;-)

Frank M. schrieb:
> Warum machst Du sowas? Der Code ist doch kompletter Unsinn?!?

selbstverständlich ist der Code Unsinn! Das haben Beispiele oft so an 
sich!

Es geht doch darum, zu hinterfragen was passiert eigentlich: wenn solch 
Code mal auf einer Maschine mit 128Bit Adressraumbreite läuft und 
Adressen mittels long auf 64Bit gecastet sind!

Mit der Prozessorbitbreite hat das erst mal gar nichts zu tun!

Walter K. schrieb:
> Es geht doch darum, zu hinterfragen was passiert eigentlich: wenn solch
> Code mal auf einer Maschine mit 128Bit Adressraumbreite läuft und
> Adressen mittels long auf 64Bit gecastet sind!

Warum willst Du das wissen? Überhaupt einen Gedanken zu verschwenden, ob 
wann wo das läuft oder nicht, ist Zeitverschwendung. Es gibt tausend 
Wege, sich in den Fuß zu schießen. Deiner ist nur einer von vielen.

Tom schrieb:
> Der Code kracht auf meinem 64-Bit-PC schon mit seg fault. Wahrscheinlich
> eine Verschwörung der Lügencompiler.

Nee kein Lügencompiler --- aber ganz sicher Windows ;-)

Walter K. schrieb:
> selbstverständlich ist der Code Unsinn! Das haben Beispiele oft so an
> sich!

Nein, nur die abschreckenden Beispiele, wie man es nicht machen soll.

Walter K. schrieb:
> nachfolgender Code dürfte ja zukünftig z.B. auf 128Bit Maschinen gegen
> die Wand laufen:

Der läuft auch schon bei gängigen X86_64 Maschinen schief, denn int ist 
da oft nur 32-bittig.

Anderes Beispiel wären 8051 Compiler, dort ist i.d.R. sizeof(void*) = 3 
(bytes), weil man so die unterschiedlichen Speichertypen (code, data, 
xdata) abhandeln kann.

Moin,

Voellig OT; meine Lieblingsfehlermeldung des gcc:

1

echo "main(){ long long long bla=3;}" | gcc -xc -

2

<stdin>: In function 'main':

3

<stdin>:1:19: error: 'long long long' is too long for GCC

Gruss
WK

Walter K. schrieb:
> Frank M. schrieb:
>> Warum machst Du sowas? Der Code ist doch kompletter Unsinn?!?
>
> selbstverständlich ist der Code Unsinn! Das haben Beispiele oft so an
> sich!

Nur Beispiele, die zeigen, wie man etwas nicht macht. Das tut deins 
auch.

> Es geht doch darum, zu hinterfragen was passiert eigentlich: wenn solch
> Code mal auf einer Maschine mit 128Bit Adressraumbreite läuft und
> Adressen mittels long auf 64Bit gecastet sind!

Mist passiert da, weil man einen Fehler im Programm hat.

> Mit der Prozessorbitbreite hat das erst mal gar nichts zu tun!

Schon alleine deshalb, weil die Breite eines Zeiger auch nicht der 
nativen Breite eines Integers der Plattform entsprechen muss. Es darf 
auch Plattformen geben, wo ein int 128 Bit breit ist und ein Zeiger nur 
32 Bit. Oder umgekehrt.

Dergute W. schrieb:
> <stdin>:1:19: error: 'long long long' is too long for GCC

Da musste ich natürlich ausprobieren, was bei "short short" rauskommt, 
aber da ist die Fehlermeldung viel langweiliger:

shortshort.c:19:7: error: duplicate ‘short’

mh schrieb:
> Ma W. schrieb:
>> Walter K. schrieb:
>>> int ptr;
>>>
>>> *((unsigned long *) ptr) = malloc(strlen(string) + 1);
>>
>> hier wird ptr uninitialisiert verwendet.
>> Ende der Analyse.
>
> ptr ist nicht uninitialisiert, ptr ist kein Pointer.

Ob Pointer oder nicht, spielt keine Rolle. Ein int als lokale Variable 
wird genauso wenig initialisiert wie ein Pointer, wenn man das nicht 
epxlizit tut.

> Die Zeile ist allerdings mindestens implementation defined und undefined,
>  wenn der Rückgabewert von malloc nicht als int dargestellt werden kann,
> oder long nicht die gleiche Breite wie int hat.

Er schreibt den Rückgabewert von malloc nicht in den int. Er 
interpretiert den (uninitialisierten) int als Zeiger auf unsigned long 
und schreibt den Rückgabewert dorthin, wohin dieser zeigt.

Rad ab schrieb:
> Linglonger!

Finglonger?
http://futurama.wikia.com/wiki/Fing-Longer

nicht besser? schrieb:
> Frank M. schrieb:
>> ptr = malloc(strlen(string) + 1);
>
> Warum nicht sizeof()

Wenn schon ein schlechtes Beispiel, dann gleich richtig schlecht...

nicht besser? schrieb:
> Frank M. schrieb:
> ptr = malloc(strlen(string) + 1);
>
> Warum nicht sizeof()

Ich schrieb doch,  dass man einiges optimieren kann. Das war aber nicht 
die Aufgabe. Daher habe ich den vorliegenden Code einfach 
1:1"übersetzt".