c & time problem

[RVO]

Hi,
I am having a problem understanding why this code works.
As I understand it the "ctime" function returns a string. In main the
returned "string" is assigned to an integer (16 bit) and is printed with
a string format in MAIN.
Would someone kindly explain how this works and/or correct my understanding?

#include <stdio.h>
#include <time.h>
// Gets System Date and Time
int main(void)
{
int i;
i = mytim();
printf("D/T= %s", i);
}

mytim()
{
time_t now;
if( (now = time(NULL)) == (time_t) - 1 )
puts("FAIL: Unable to get time");
else
printf("Date & time: %s", ctime(&now));

// Either of following works equally well
return (ctime(&now));
}

 

[Ian Collins]

Hi,
I am having a problem understanding why this code works.
As I understand it the "ctime" function returns a string. In main the
returned "string" is assigned to an integer (16 bit) and is printed with
a string format in MAIN.

Why do you assume 16 bit int? The function name is main, not MAIN.

Would someone kindly explain how this works and/or correct my
understanding?

#include <stdio.h>
#include <time.h>
// Gets System Date and Time
int main(void)
{
int i;
i = mytim();
printf("D/T= %s", i);
}

mytim()

Don't rely on implicit int return type.

{
time_t now;
if( (now = time(NULL)) == (time_t) - 1 )
puts("FAIL: Unable to get time");
else
printf("Date & time: %s", ctime(&now));
// Either of following works equally well
return (ctime(&now));
}

Did you take note of all of the compiler warnings emitted when you
compiled this?

A classic case of undefined behaviour, sizeof char* happens to equal
sizeof int.

 

[RVO]

RVO wrote:



Why do you assume 16 bit int? The function name is main, not MAIN.

1) because it is.
2) MAIN for emphasis.

Don't rely on implicit int return type.

3) Got code from "C" expert on web.

Did you take note of all of the compiler warnings emitted when you
compiled this?

4) the warning was not related to this as far as I can tell.

A classic case of undefined behaviour, sizeof char* happens to equal
sizeof int.

5) But if "C" is so unique why does it not flag the %s usage with the
integer?

 

[Ian Collins]

1) because it is.

On what?

3) Got code from "C" expert on web.

One to avoid then.

4) the warning was not related to this as far as I can tell.

/tmp/x.c: In function `main':
/tmp/x.c:7: warning: implicit declaration of function `mytim'
/tmp/x.c:8: warning: format argument is not a pointer (arg 2)
/tmp/x.c:9: warning: control reaches end of non-void function
/tmp/x.c: At top level:
/tmp/x.c:12: warning: return type defaults to `int'
/tmp/x.c: In function `mytim':
/tmp/x.c:19: warning: return makes integer from pointer without a cast

Which one? The warning for line 8 looks plain enough. Perhaps you
didn't invoke your compiler in conforming mode.

5) But if "C" is so unique why does it not flag the %s usage with the
integer?

gcc did, see above.

 

[Ian Collins]

gcc did, see above.

I should point out that this warning is (possibly) unique to gcc. The
compiler is not required (or able without knowledge of the passed
arguments) to type check arguments passed to a variadic function like
printf. Doing so requires compile time parsing of the argument list.

 

[CBFalconer]

1) because it is.

No it isn't necessarily. You can draw some conclusions from the

2) MAIN for emphasis.
Silly.

3) Got code from "C" expert on web.

He wasn't an expert.
.... snip ...

 

[Andrew Poelstra]

1) because it is.

No, it isn't. You need to understand that to use C.

2) MAIN for emphasis.

Just write main(). It's significance in your program implies emphasis.

3) Got code from "C" expert on web.

So? If everyone on the web who claimed to know C actually did, this
group wouldn't have nearly as much traffic, would it?

I should also mention that you shouldn't use // commments. They aren't
valid in C90, and (more importantly) will not display correctly on
Usenet unless great care is taken.

4) the warning was not related to this as far as I can tell.

So you ignored it? You need to take note of /all/ warnings, /always/.
Always. I cannot stress that enough.

5) But if "C" is so unique why does it not flag the %s usage with the
integer?

Because it's a language? Not many languages have the capacity for verbs
like "flag". They fail to even really exist unless someone takes the
time to write them down.

 

[RVO]

RVO wrote:



On what?



One to avoid then.



/tmp/x.c: In function `main':
/tmp/x.c:7: warning: implicit declaration of function `mytim'
/tmp/x.c:8: warning: format argument is not a pointer (arg 2)
/tmp/x.c:9: warning: control reaches end of non-void function
/tmp/x.c: At top level:
/tmp/x.c:12: warning: return type defaults to `int'
/tmp/x.c: In function `mytim':
/tmp/x.c:19: warning: return makes integer from pointer without a cast

Which one? The warning for line 8 looks plain enough. Perhaps you
didn't invoke your compiler in conforming mode.




gcc did, see above.

Really wish that when people respond to a query they would address the
points made. I do not intend to carry this conversation further with
your bombastic supercilious remarks.

 

[RVO]

No, it isn't. You need to understand that to use C.




Just write main(). It's significance in your program implies emphasis.



So? If everyone on the web who claimed to know C actually did, this
group wouldn't have nearly as much traffic, would it?

I should also mention that you shouldn't use // commments. They aren't
valid in C90, and (more importantly) will not display correctly on
Usenet unless great care is taken.



So you ignored it? You need to take note of /all/ warnings, /always/.
Always. I cannot stress that enough.




Because it's a language? Not many languages have the capacity for verbs
like "flag". They fail to even really exist unless someone takes the
time to write them down.

I have little to learn from this group. Thank you for wasting my time.

 

[Richard Heathfield]

RVO said:

Hi,
I am having a problem understanding why this code works.
As I understand it the "ctime" function returns a string. In main the
returned "string" is assigned to an integer (16 bit) and is printed with
a string format in MAIN.
Would someone kindly explain how this works and/or correct my
understanding?

The code "works" (in the loosest sense of the word) because the platform you
are using happens to convert from char * to int without loss of information
or corruption of representation. Not all platforms do so, so your instincts
are dead right - the code is broken, even though it "works" on your
platform.

<snip>

 

[Nick Keighley]

I am having a problem understanding why this code works.
As I understand it the "ctime" function returns a string. In main the
returned "string" is assigned to an integer (16 bit) and is printed with
a string format in MAIN.
Would someone kindly explain how this works and/or correct my understanding?

#include <stdio.h>
#include <time.h>
// Gets System Date and Time
int main(void)
{
int i;
i = mytim();
printf("D/T= %s", i);
}

mytim()
{
time_t now;
if( (now = time(NULL)) == (time_t) - 1 )
puts("FAIL: Unable to get time");
else
printf("Date & time: %s", ctime(&now));

// Either of following works equally well
return (ctime(&now));
}

this is absolutely awful code that simply crawls with Undefined
Behaviour. That
is the C standard does not specify the semantics of programs that have
these
constructs, consequently the implementer can do what he damn well
pleases.

Hence "why does this work?" is not a meaningful question.

Why does it seem to "work" then? Well if mytim returns a string in C
it actually returns a char* (ptr-to-char). A pointer is often
implemented as
a machine address. The machine address gets stuffed into an int. You
claim ints are16-bit on your platform. So I guess addresses are 16-bit
(unusual...) on your platform. You then tell printf() to print an int
as if it
were a char*, and printf() does its best with the mutilated machine
address.
This motley collection of UB then produces what you think is sensible
output. On you platform. This time. Don't rely on UB.

Tip for the future- if you ask for help don't be rude to those who try
to
help you. I'm giving you the benefit of the doubt this time.