Thread: Function not returning date string

Code:

#include<stdio.h>
#include<time.h>
#include<stdlib.h>
#include<string.h>

void date(char *);

int main(void)
{
    char dtstr[11];
    date(dtstr);
    puts(dtstr);
    return 0;
}

void date(char *)
{
    int day, month, year;
    time_t now;
    time(&now);
    struct tm *local = localtime(&now);
    day = local->tm_mday;        
    month = local->tm_mon + 1;       
    year = local->tm_year + 1900;    

    char dtstr[11];

    char d[2];
    sprintf(d,"%d",day);
            
    char m[2];
    sprintf(m,"%d",month);
    
    char y[4];
    sprintf(y,"%d",year);

    strcat(dtstr,d);
    strcat(dtstr,"/");
    strcat(dtstr,m);
    strcat(dtstr,"/");
    strcat(dtstr,y);
//    puts(dtstr);
}

Why is dtstr not available for printing in main()?

I don't really understand why this is better (it works)

Code:

#include<stdio.h>
#include<time.h>
#include<stdlib.h>
#include<string.h>

void date(char *);

int main(void)
{
    char dtstr[10];
    date(dtstr);
    puts(dtstr);
    return 0;
}

void date(char *word)
{
    int day, month, year;
    time_t now;
    time(&now);
    struct tm *local = localtime(&now);
    day = local->tm_mday;        
    month = local->tm_mon + 1;       
    year = local->tm_year + 1900;    

    char dtstr[10];

    char d[2];
    sprintf(d,"%d",day);
            
    char m[2];
    sprintf(m,"%d",month);
    
    char y[4];
    sprintf(y,"%d",year);

    strcat(dtstr,d);
    strcat(dtstr,"/");
    strcat(dtstr,m);
    strcat(dtstr,"/");
    strcat(dtstr,y);
    strcpy(word,dtstr);
//    puts(dtstr);
}

I don't really understand why this is better (it works)

Well your first code shouldn't even compile if you are indeed using a C, not C++ compiler.

You need to name the parameters in your function implementation in order to use them in the function.


By the way you're probably invoking undefined behaviour in this snippet:

Code:

    char d[2];
    sprintf(d,"%d",day);

If day is larger than 9 you overflow the bounds of the array d. You need to have room for the end of string character, so you need an array of at least size 3.

Edit: All of your arrays have this problem.

Originally Posted by jimblumberg

Well your first code shouldn't even compile if you are indeed using a C, not C++ compiler.

You need to name the parameters in your function implementation in order to use them in the function.


By the way you're probably invoking undefined behaviour in this snippet:

Code:

    char d[2];
    sprintf(d,"%d",day);

If day is larger than 9 you overflow the bounds of the array d. You need to have room for the end of string character, so you need an array of at least size 3.

Edit: All of your arrays have this problem.

Yes, I will need to correct the widths.

I really do not understand this sentence, and I feel that sentence hits the heart of the matter:

"You need to name the parameters in your function implementation in order to use them in the function." Have I not done so in the current code? This code does he job. I thought that by introducing the variable "word" I did what you said that needed doing. Could you please formulate that crucial sentence alternatively so I can understand?

By the way I believe the compiler I use is some sort of a hybrid, does both I think.

Have I not done so in the current code? This code does he job. I thought that by introducing the variable "word" I did what you said that needed doing.

Yes you have but I was answering your question:

I don't really understand why this is better (it works)

The answer is to name your parameters, then the the program has a chance of working.

By the way I believe the compiler I use is some sort of a hybrid, does both I think.

Well then you need to read the documentation for your compiler and "force" it to use the C compiler. There are differences between the two compilers. For example it is legal to have un-named parameters in C++ but not legal in C. By the way in C++ an un-named parameter means that to call the function you need to supply the parameter, but that parameter will not be used.

Originally Posted by jimblumberg

Yes you have but I was answering your question:

<snipped>

Code:

char d[2];
sprintf(d,"%d",day);

d[2] has: d[0], d[1] and d[2]. For month with 31 days it also has room for the closing '\0', which needs one character. Is this all wrong?

d[2] has: d[0], d[1] and d[2]. For month with 31 days it also has room for the closing '\0', which needs one character. Is this all wrong?

Not all wrong, but still wrong. Yes an array with the size of 2 has elements of 0 and 1. However this means that there can only be one digit because you must terminate a string with the '\0' character.

Originally Posted by jimblumberg

Not all wrong, but still wrong. Yes an array with the size of 2 has elements of 0 and 1. However this means that there can only be one digit because you must terminate a string with the '\0' character.

How stupid of me.

Originally Posted by Hodor

Errr... d[2] has two elements: d[0] and d[1] (d[2] would be outside of the array)

Edit: just saw jimblumberg has already answered. The speed of the forum is messing with my mind I could have sworn the reply was not there a few seconds ago :/

The site is suddenly faster. It has been wasting much of my time and patience. I thought it was being run from some little laptop or so.

Originally Posted by Hodor

It's so slow it's stupid. The reason it's slow is because of DDoS (apparently) and the webmaster mustn't have shell access to add firewall rules to drop the offending traffic. Either that or the webmaster doesn't know how to set it up. Two weeks (maybe more) this DDoS has been going on for with no apparent effort by the webmaster to stop it LOL

It is not necessarily DDoS. There are many reasons the site is not responsive. I suspect they are working on whatever the issue is.

DDoS is probably at the very bottom of the list of possibilities.

Originally Posted by rstanley

It is not necessarily DDoS. There are many reasons the site is not responsive. I suspect they are working on whatever the issue is. DDoS is probably at the very bottom of the list of possibilities.

The biggest enemy of C is Microsoft. It is a bit of the market they have not yet grabbed.