Größe von 'time_t' ?

[SBond]

Hallo Leute,

ich habe in PB Funktionen eingebunden, mit denen ich Zeitmessungen durchführen kann...

Code: Alles auswählen

[...]
	CompilerCase #PB_OS_Linux
		;Clock-ID's = Type of clock to use
		#CLOCK_REALTIME            = 0
		#CLOCK_MONOTONIC           = 1
		#CLOCK_PROCESS_CPUTIME_ID  = 2
		#CLOCK_THREAD_CPUTIME_ID   = 3
		#CLOCK_REALTIME_HR         = 4
		#CLOCK_MONOTONIC_HR        = 5
		
		Structure timespec
			tv_sec.???
			tv_nsec.l
		EndStructure
		
		ImportC ""
			clock_getres.i(clock_id.i, *res.timespec)
			clock_gettime.i(clock_id.i, *tp.timespec)
		EndImport

[...]

die Struktur 'timespec' wird wie folgt definiert:

Code: Alles auswählen

    struct timespec
       {
          time_t   tv_sec;   /* seconds *
          long     tv_nsec;  /* nanoseconds *
       }

'tv_nsec' ist ein normaler Long und somit 4 Byte groß. Wie sieht es mit 'tv_sec' aus? Ich finde keine eindeutigen Angaben. Es ist entweder ein long oder ein long long. Kann ich notfalls ein long long (tv_nsec.q) daraus machen oder besteht die Gefahr, dass beim befüllen der Struktur Fehler auftreten.

viele Grüße,
SBond

[ts-soft]

time_t sollte ein Integer sein! Also long auf 32-bit und quad auf 64-bit.

Gruß
Thomas

[SBond]

ahh ok.

Ich bin bei sowas immer sehr vorsichtig, da ich zumindest unter C++ schon öfters Probleme bei falscher Dimensionierung hatte.

[Sicro]

Kann ich notfalls ein long long (tv_nsec.q) daraus machen oder besteht die Gefahr, dass beim befüllen der Struktur Fehler auftreten.

Nehmen wir mal an, die Funktion erwartet tv_sec und tv_nsec als Long, du definierst tv_sec jedoch als Quad (Doppel-Long), dann schreibt die Funktion beide Werte (tv_sec und tv_nsec) in tv_sec, weil ja beide Longs in das Quad passen und tv_nsec bleibt unberührt.

Die Funktion weiß nicht, dass der Speicher von dir strukturiert ist, weil ein strukturierter und unstrukturierter Speicher gleich aussieht. Die Struktur, die du definierst, erleichtert dir nur den Zugriff auf die Teildaten des Speichers, da du nicht mit Bytes rechnen musst, sondern nur noch angeben brauchst: Ich will tv_sec. Der Computer weiß, weil du das ja so definiert hast, dass tv_sec hier im Beispiel 4-Bytes groß ist (eine Long-Variable) und liest die aus dem Speicher. Möchtest du tv_nsec, weiß der Computer er muss die 4-Bytes von tv_sec überspringen und dann 4-Bytes für tv_nsec lesen.

Die Struktur gibt es also im fertigem (kompiliertem) Programm-Code nicht mehr, sondern nur noch die aus der Struktur berechneten Positionen und Längen in Bytes.

[Makke]

Hi SBond,

hiernach sollte es sich immer um ein Long handeln. Siehe da:

http://www.cs.fsu.edu/~baker/devices/lx ... s_64.h#L21
und da
http://www.cs.fsu.edu/~baker/devices/lx ... s_32.h#L21
und hier die Struktur
http://www.cs.fsu.edu/~baker/devices/lx ... nux/time.h

Hoffe das hilft Dir.

[ts-soft]

Note that GTime is defined to always be a 32-bit integer, unlike time_t which may be 64-bit on some systems.

Demnach ist es Integer, anders als GTime. Aber will mich da nicht festlegen
da ich nicht weiß was "some systems" sind. Für mich hört sich das an, wie alle 64-Bit Architekturen.

[SBond]

Nehmen wir mal an, die Funktion erwartet tv_sec und tv_nsec als Long, du definierst tv_sec jedoch als Quad (Doppel-Long), dann schreibt die Funktion beide Werte (tv_sec und tv_nsec) in tv_sec, weil ja beide Longs in das Quad passen und tv_nsec bleibt unberührt.

exakt. Genau das meinte ich.


@Makke: Aber auch auf 64-Bit systeme?

[Makke]

Der zweite Link ist für 64bit Systeme der dritte für 32bit. Demnach ist es immer ein Long.

[NicTheQuick]

Ich hab erst vor kurzem hier irgendwo einen Code veröffentlicht, wo ich diese Struktur im Kommentar genau aufgeschlüsselt. Ich habe nur leider keine Lust auf meinem Smartphone hier im Forum zu suchen. Sollte aber einer der neueren Beiträge sein. Jedenfalls ist es bei mir immer Quad gewesen, soweit ich mich erinnere.

[SBond]

meinst du diesen?: http://www.purebasic.fr/german/viewtopi ... 12#p325012

Code: Alles auswählen

;Linux only
Structure timeval
 	tv_sec.q   ;__time_t      -> __TIME_T_TYPE      -> __SYSCALL_SLONG_TYPE -> __SQUAD_TYPE -> long int | __quad_t
 	tv_usec.q  ;__suseconds_t -> __SUSECONDS_T_TYPE -> __SYSCALL_SLONG_TYPE -> __SQUAD_TYPE -> long int | __quad_t
 EndStructure
 
 Procedure.d seconds()
 	Protected tim.timeval
 	gettimeofday_(tim, #Null)
 	ProcedureReturn tim\tv_sec + tim\tv_usec / 1000000.
 EndProcedure
 
 Define today.d = seconds()
 Define seconds.q = Round(today, #PB_Round_Down)
 Define hours.q = seconds / 3600
 Define minutes.q = seconds / 60 - 60 * hours
  seconds % 60
 hours % 24
 Debug "Zeit: " + hours + ":" + minutes + ":" + today
 
 Define time.d = seconds()
 Delay(1000)
 time = seconds() - time
 Debug time

puh... ich hätte nicht gedacht, dass mir so eine kleine Struktur derartige Probleme bereitet. Wenn man mal in PB-Foren sucht, dann findet man diese Struktur mal mit integer und mal mit long. Ich wollte nur sichergehen, das die Struktur je nach Architektur sicher ist.

@Makke: Hatte mich bei den Links gewundert, dass oben in der Seite "Architecture: [ i386 ]" stand. Hätte ja eigentich auch ein long long erwartet, denn ein einfacher long verursacht das Jahr 2038-Problem. Eventuell denke ich auch einfach zu weit und die Lösung ist ganz einfach.

...notfalls mach ich einfach aus beidem ein Long, so wie es in der Seite steht. Ist keine wirklich schöne Lösung, aber naja ^^...

Code: Alles auswählen

[...]

CompilerCase #PB_OS_Linux
	; Clock-IDs
	#CLOCK_REALTIME			= 0
	#CLOCK_MONOTONIC			= 1
	#CLOCK_PROCESS_CPUTIME_ID	= 2
	#CLOCK_THREAD_CPUTIME_ID	= 3
	#CLOCK_MONOTONIC_RAW		= 4
	#CLOCK_REALTIME_COARSE		= 5
	#CLOCK_MONOTONIC_COARSE	= 6
	#CLOCK_BOOTTIME			= 7
	#CLOCK_REALTIME_ALARM		= 8
	#CLOCK_BOOTTIME_ALARM		= 9
	
	Structure timespec
		tv_sec.l
		tv_nsec.l
	EndStructure
[...]

ich danke euch wieder für eure Hilfe.