Home > Archive > Unix Programming > June 2007 > check if a variable is time_t
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
check if a variable is time_t
|
|
| Pietro Cerutti 2007-06-26, 10:06 pm |
| Hi group,
I have to cast a void pointer to a known structure pointer which
contains (among other fields) a time_t variable and I'm writing a
function to perform a sanity check on the casted data.
Which is the best way to check if the time_t variable contains valid data?
Thanks,
--
Pietro Cerutti
PGP Public Key:
http://gahr.ch/pgp
| |
| Måns Rullgård 2007-06-26, 10:06 pm |
| Pietro Cerutti <gahr@gahr.ch> writes:
> Hi group,
>
> I have to cast a void pointer to a known structure pointer which
If this is C (not C++), there is no need for an explicit cast. A
simple assignment will do fine, and is actually the preferred way.
Explicit casts can hide errors. This isn't what you asked about,
but it's such a common error that I'm mentioning it nonetheless.
> contains (among other fields) a time_t variable and I'm writing a
> function to perform a sanity check on the casted data.
>
> Which is the best way to check if the time_t variable contains valid
> data?
You can't. Any value is valid.
It sounds to me like you're not certain that the pointer is what you
think it is. If this is the case, rethink your design, preferably
without using void pointers. That way, the compiler will make sure
everything has the proper type for you.
--
Måns Rullgård
mans@mansr.com
| |
| Pietro Cerutti 2007-06-26, 10:06 pm |
| M=E5ns Rullg=E5rd wrote:
> Pietro Cerutti <gahr@gahr.ch> writes:
>=20
>=20
> If this is C (not C++), there is no need for an explicit cast. A
> simple assignment will do fine, and is actually the preferred way.
> Explicit casts can hide errors. This isn't what you asked about,
> but it's such a common error that I'm mentioning it nonetheless.
Yes it's C, and yes, you're right..
>=20
>=20
> You can't. Any value is valid.
>=20
> It sounds to me like you're not certain that the pointer is what you
> think it is. If this is the case, rethink your design, preferably
> without using void pointers. That way, the compiler will make sure
> everything has the proper type for you.
>=20
The void pointer I mentioned is data received from the network.
At one endpoint I send the contents of the structure and at the other
endpoint I want to check whether what I received is valid for that
structure, that's why I'm not certain that the pointer is that I this it =
is.
I ended up checking whether that value is not smaller than what
time(NULL) returns minus 60 and not greater than what time(NULL)
returns, i.e. if it's a valid time, it represent the time in the last
minute.
Tnx.
--=20
Pietro Cerutti
PGP Public Key:
http://gahr.ch/pgp
| |
| Eric Sosman 2007-06-26, 10:06 pm |
| Pietro Cerutti wrote On 06/26/07 14:34,:
> M=E5ns Rullg=E5rd wrote:
>=20
>=20
>=20
> Yes it's C, and yes, you're right..
>=20
>=20
>=20
>=20
> The void pointer I mentioned is data received from the network.
> At one endpoint I send the contents of the structure and at the other
> endpoint I want to check whether what I received is valid for that
> structure, that's why I'm not certain that the pointer is that I this i=
t is.
>=20
> I ended up checking whether that value is not smaller than what
> time(NULL) returns minus 60 and not greater than what time(NULL)
> returns, i.e. if it's a valid time, it represent the time in the last
> minute.
You should probably accept time_t values in the "near
future," too. The clock on the computer that sent you the
message may be a little bit ahead of your local clock ...
You've got a (potentially) worse problem, though. If
the computer on the other side of the network is not the
same kind as yours or is running a different O/S, its time_t
representation may be different from yours. Even if both
are POSIX systems that count seconds since the Epoch, you
still need to take care of endianness -- of representation
issues in general. You would be *much* better off using a
text format for over-the-network exchanges between what
might be dissimilar machines. You don't need to go all the
way through strftime on output and strptime on input; even
a digit string representing a plain seconds count would
avoid a good deal of trouble.
--=20
Eric.Sosman@sun.com
| |
| Måns Rullgård 2007-06-26, 10:06 pm |
| Pietro Cerutti <gahr@gahr.ch> writes:
> Måns Rullgård wrote:
>
> The void pointer I mentioned is data received from the network. At
> one endpoint I send the contents of the structure and at the other
> endpoint I want to check whether what I received is valid for that
> structure, that's why I'm not certain that the pointer is that I
> this it is.
Your mistake here is dumping a struct as-is over a socket. The proper
way is to implement some encapsulating protocol that properly
identifies the data.
> I ended up checking whether that value is not smaller than what
> time(NULL) returns minus 60 and not greater than what time(NULL)
> returns, i.e. if it's a valid time, it represent the time in the last
> minute.
For your description is wasn't clear that the value would always be a
current time. I'd probably allow a little slack both ways though, to
account for the other system clock being ahead of the local clock.
How much deviation to tolerate depends on circumstances. If all
systems involved can be assumed to run NTP or equivalent, the clocks
should be within milliseconds of each other. If not, deviations of a
minute or two either way should be expected. Computer clocks tend to
be rather inaccurate.
--
Måns Rullgård
mans@mansr.com
| |
| Pietro Cerutti 2007-06-26, 10:06 pm |
| Eric Sosman wrote:
> Pietro Cerutti wrote On 06/26/07 14:34,:
[color=darkred]
it is.[color=darkred]
>=20
> You should probably accept time_t values in the "near
> future," too. The clock on the computer that sent you the
> message may be a little bit ahead of your local clock ...
Thanks for the hint.
>=20
> You've got a (potentially) worse problem, though. If
> the computer on the other side of the network is not the
> same kind as yours or is running a different O/S, its time_t
> representation may be different from yours. Even if both
> are POSIX systems that count seconds since the Epoch, you
> still need to take care of endianness -- of representation
> issues in general. You would be *much* better off using a
> text format for over-the-network exchanges between what
> might be dissimilar machines. You don't need to go all the
> way through strftime on output and strptime on input; even
> a digit string representing a plain seconds count would
> avoid a good deal of trouble.
>=20
What about using htonl and ntohl on the value before sending / after
receiving it?
P.S.
The POSIX compliance of all machines participating is assumed by design.
--=20
Pietro Cerutti
PGP Public Key:
http://gahr.ch/pgp
| |
| Eric Sosman 2007-06-26, 10:06 pm |
| Pietro Cerutti wrote On 06/26/07 15:34,:
> Eric Sosman wrote:
> [...]
>
> What about using htonl and ntohl on the value before sending / after
> receiving it?
You could do that, if you assume time_t is 32 bits
on both systems. If you encounter a machine where time_t
is 64 bits (one suggested cure for "the 2038 bug"), you'll
still have trouble.
Another problem with just blasting a struct out over
the network is that the communicating systems may pad the
struct differently to satisfy differing alignment needs.
Simply finding the time_t within the struct may be non-
trivial.
--
Eric.Sosman@sun.com
| |
| Pietro Cerutti 2007-06-26, 10:06 pm |
| Eric Sosman wrote:
> Pietro Cerutti wrote On 06/26/07 15:34,:
>
> You could do that, if you assume time_t is 32 bits
> on both systems. If you encounter a machine where time_t
> is 64 bits (one suggested cure for "the 2038 bug"), you'll
> still have trouble.
>
> Another problem with just blasting a struct out over
> the network is that the communicating systems may pad the
> struct differently to satisfy differing alignment needs.
> Simply finding the time_t within the struct may be non-
> trivial.
>
I see... so the only safe thing to do is to send char arrays?
Tnx
--
Pietro Cerutti
PGP Public Key:
http://gahr.ch/pgp
| |
| Måns Rullgård 2007-06-26, 10:06 pm |
| Eric Sosman <Eric.Sosman@sun.com> writes:
> Pietro Cerutti wrote On 06/26/07 15:34,:
>
> You could do that, if you assume time_t is 32 bits
> on both systems. If you encounter a machine where time_t
> is 64 bits (one suggested cure for "the 2038 bug"), you'll
> still have trouble.
Most 64-bit systems have a 64-bit time_t, and they're getting quite
common these days.
--
Måns Rullgård
mans@mansr.com
| |
| Måns Rullgård 2007-06-26, 10:06 pm |
| Pietro Cerutti <gahr@gahr.ch> writes:
> Eric Sosman wrote:
>
> I see... so the only safe thing to do is to send char arrays?
You could use something like XDR to convert to/from a byte-serial
form.
--
Måns Rullgård
mans@mansr.com
| |
| Eric Sosman 2007-06-27, 7:08 pm |
| Pietro Cerutti wrote:
> Eric Sosman wrote:
>
> I see... so the only safe thing to do is to send char arrays?
It's not the *only* safe thing, but it is *a* safe thing
that has the virtues of convenience and simplicity. There
are other safe approaches, like settling on a "wire format"
that all the communicating machines will use, even if it
doesn't happen to match their own internal representations.
(The XDR formats mentioned by Måns Rullgård could be the
basis of such a protocol.)
BUT: This thread started with your question about how to
determine whether some bag of bytes was or was not a time_t.
If you were using an agreed-upon protocol you would already
*know* that bytes eight through eleven (or whatever) are a
time_t; the question of identifying a time_t in the midst of
a sea of confusion simply wouldn't arise. Therefore I've been
assuming that the message format is *not* tightly defined --
and if that's the case, I don't see how htonl or XDR or any
other binary convention is likely to be practical. Hence my
suggestion of a text-based format -- for example, messages
consisting of comma-separated text fields such as you'd find
when exporting a spreadsheet to "CSV format." Formats of
this kind have useful "anchor points" that permit recovery
after some sort of confusion: the commas between fields, or
the newlines between successive lines, for example. Binary
formats, by and large, don't resynchronize quite so easily.
If you're willing to spend the effort to adopt a binary
"wire format" and make all the communicating machines support
it, that's likely to be the most efficient in terms of both
CPU effort and message size. But if the machines only "sort
of" agree on a format, I'd strongly recommend text -- you
could even go to the extreme of using XML, if it came to that.
--
Eric Sosman
esosman@acm-dot-org.invalid
| |
| Pietro Cerutti 2007-06-27, 7:08 pm |
| Eric Sosman wrote:
> Pietro Cerutti wrote:
>=20
> It's not the *only* safe thing, but it is *a* safe thing
> that has the virtues of convenience and simplicity. There
> are other safe approaches, like settling on a "wire format"
> that all the communicating machines will use, even if it
> doesn't happen to match their own internal representations.
> (The XDR formats mentioned by M=E5ns Rullg=E5rd could be the
> basis of such a protocol.)
Indeed, after reading some lines here and there and doing some research
I decided to XDR my data.
>=20
> BUT: This thread started with your question about how to
> determine whether some bag of bytes was or was not a time_t.
> If you were using an agreed-upon protocol you would already
> *know* that bytes eight through eleven (or whatever) are a
> time_t; the question of identifying a time_t in the midst of
> a sea of confusion simply wouldn't arise. Therefore I've been
> assuming that the message format is *not* tightly defined --
> and if that's the case, I don't see how htonl or XDR or any
> other binary convention is likely to be practical. Hence my
> suggestion of a text-based format -- for example, messages
> consisting of comma-separated text fields such as you'd find
> when exporting a spreadsheet to "CSV format." Formats of
> this kind have useful "anchor points" that permit recovery
> after some sort of confusion: the commas between fields, or
> the newlines between successive lines, for example. Binary
> formats, by and large, don't resynchronize quite so easily.
Well, I originally asked about a simple / known / standard way to decide
whether, say, 13449275359 is a valid time_t value.
I know understand that probably any value of time_t is "valid" as a
timestamp, and that my question would probably have been better asked as
"How can I determine if a time_t value is 'not to far' from now?", which
I already solved using some basic arithmetics on the value itself and on
the return value of time(NULL).
So thank you (Eric and M=E5ns) for your directions and advices.
--=20
Pietro Cerutti
PGP Public Key:
http://gahr.ch/pgp
|
|
|
|
|