error problems

[Bill Cunningham]

I just about have the code I wanted to write written. It compiles but I
have these error codes. This has yet to be converted into an object file and
compiled with some code. What do these errors mean? The compiler wants a
cast and I don't know if I need to convert types use a cast to a similar
type or what. I've tried both these things. Any ideas?

#include <stdio.h>

#define type unsigned int

struct stk {
type date[6];
type price;
type volume;
};

struct stk s, *ps;
struct stk packs(type date[6], type price, type volume)
{
s.date[6] = date[6];
s.price = price;
s.volume = volume;
return s;
}

type unpacks(struct stk * date[6], struct stk * price, struct stk * volume)
{
type date[6];
type price;
type volume;
return date[6] = ps->date;
return price = ps->price;
return volume = ps->volume;

}

mo.c: In function `unpacks':
mo.c:22: warning: declaration of `date' shadows a parameter
mo.c:23: warning: declaration of `price' shadows a parameter
mo.c:24: warning: declaration of `volume' shadows a parameter
mo.c:25: warning: assignment makes integer from pointer without a cast

 

[Fred]

    I just about have the code I wanted to write written. It compiles but I
have these error codes. This has yet to be converted into an object file and
compiled with some code. What do these errors mean? The compiler wants a
cast and I don't know if I need to convert types use a cast to a similar
type or what. I've tried both these things. Any ideas?

#include <stdio.h>

#define type unsigned int

struct stk {
    type date[6];
    type price;
    type volume;

};

struct stk s, *ps;
struct stk packs(type date[6], type price, type volume)
{
    s.date[6] = date[6];
    s.price = price;
    s.volume = volume;
    return s;

}

type unpacks(struct stk * date[6], struct stk * price, struct stk * volume)

Here you claim that "date" is an array of 6 pointers to struct stk.

{
    type date[6];

But here you claim that "date" is an array of 6 unsigned ints.
Which is it?

<snip>

 

[Bill Cunningham]

I just about have the code I wanted to write written. It compiles
but I have these error codes. This has yet to be converted into an
object file and compiled with some code. What do these errors mean?
The compiler wants a cast and I don't know if I need to convert
types use a cast to a similar type or what. I've tried both these
things. Any ideas?

#include <stdio.h>

#define type unsigned int

struct stk {
type date[6];
type price;
type volume;

};

struct stk s, *ps;
struct stk packs(type date[6], type price, type volume)
{
s.date[6] = date[6];
s.price = price;
s.volume = volume;
return s;

}

type unpacks(struct stk * date[6], struct stk * price, struct stk *
volume)

Here you claim that "date" is an array of 6 pointers to struct stk.

{
type date[6];

But here you claim that "date" is an array of 6 unsigned ints.
Which is it?

<snip>

 

[Bill Cunningham]

But here you claim that "date" is an array of 6 unsigned ints.
Which is it?

Hum some kind of conversion is needed here. Thanks for waking me up.

B

 

[osmium]

I just about have the code I wanted to write written. It compiles but I
have these error codes. This has yet to be converted into an object file
and compiled with some code. What do these errors mean? The compiler wants
a cast and I don't know if I need to convert types use a cast to a similar
type or what. I've tried both these things. Any ideas?

#include <stdio.h>

#define type unsigned int

struct stk {
type date[6];
type price;
type volume;
};

Rather than fix the problem you are having, I suggest you rethink your
approach.

Draw six boxes, representing the six elements of the array known as date.
Now, pretend computers used decimal instead of binary, and fill in each of
the six boxes as they would look for February 17, 2011. Does the result look
sensible to you? I certainly hope not.

 

[Default User]

Rather than fix the problem you are having, I suggest you rethink your
approach.

Yes, he should stop . . . whatever it is that he's doing.



Brian

 

[Bill Cunningham]

But here you claim that "date" is an array of 6 unsigned ints.
Which is it?

Ok I see. I have corrected my mistake. I overlooked it. Now a word about
scope. I realize and have intentionally in the functions packs and unpacks
used the same names because I understand a type name whether declared as a
parameter or in the function body is local for that function.
struct stk s;

I have left for both functions to share I hope to remain in this .c
file's scope it need not be declared static and I usually don't super
confuse things with externs. The compiler only warns now about shadow types.

B

 

[Bill Cunningham]

Rather than fix the problem you are having, I suggest you rethink your
approach.

Draw six boxes, representing the six elements of the array known as
date. Now, pretend computers used decimal instead of binary, and fill
in each of the six boxes as they would look for February 17, 2011.
Does the result look sensible to you? I certainly hope not.

My intent was to use a 6 digit format such as 021711. That's why I used
an array of 6.

B

 

[Bill Cunningham]

Yes, he should stop . . . whatever it is that he's doing.

Oh no! No DU! This must not be on topic! When did you ever post anything
that wasn't OT? You never respond to any posters except me and it's always
OT. Let's not start trolling now.

B

 

[Ian Collins]

Oh no! No DU! This must not be on topic! When did you ever post anything
that wasn't OT? You never respond to any posters except me and it's always
OT. Let's not start trolling now.

Pot, kettle?

 

[osmium]

:

My intent was to use a 6 digit format such as 021711. That's why I used
an array of 6.

Don't use digits, use numbers. 17 is a number, it has two digits, 1 and 7.
It will be much easier to do your computation (later) if you use numbers
instead of digits. You, Bill, will have to provide a carry mechanism with
digits, the computer does it if you use numbers. Month /day/year, a three
element array. I am not saying this is the best method, but it is a big
improvement on what you have now.

 

[Tom St Denis]

:




Don't use digits, use numbers.  17 is a number, it has two digits, 1 and 7.
It will be much easier to do your computation (later) if you use numbers
instead of digits.  You, Bill, will have to provide a carry mechanism with
digits, the computer does it if you use numbers. Month /day/year, a three
element array. I am not saying this is the best method, but it is a big
improvement on what you have now.

Worse, why not use a POSIX structure compatible with functions like
localtime()/gmtime()/etc.

Tom

 

[Bill Cunningham]

Aside from all the other errors, I'm surprised that the compiler doesn't
warn about the fact that the 2nd and 3rd "return"s will never be reached.

Well I didn't use the -Wall -pedantic switches. Maybe I need these in some
kind of looping scheme.

B

 

[Bill Cunningham]

:

A linked list? Whew. For sorting I could use a std c99 function. I do
want linear sorting around these "boxes". But I'm just getting started.
Stuffing is what concerns me most.

Don't use digits, use numbers. 17 is a number, it has two digits, 1 and
7. It will be much easier to do your computation (later) if you use
numbers instead of digits. You, Bill, will have to provide a carry
mechanism

A carry mechanism?

with

 

[osmium]

A linked list? Whew. For sorting I could use a std c99 function. I do
want linear sorting around these "boxes". But I'm just getting started.
Stuffing is what concerns me most.

Where does the linked list come from? I didn't say or imply anything
involving linked lists.

A carry mechanism?

17+5 = 22, the left digit changes from 1 to 2 because of a carry. You said
earlier you wanted to compute. Addition is about the simplest computation
there is. If you treat the 7 as an element of an array, you must provide a
carry if you want to add to the 7.

One of the better answers you were given last week was to use the facilities
in <time.h> but you chose to ignore that suggestion, for reasons known only
to you, and go your own way.

If you decide to use a POSIX oriented solution, move your thread to a news
group appropriate for talking about POSIX, this is not such a group.

 

[Mickey Mouse]

The world has had 10 years to forget - and has successfully forgotten.

Sadly.

I use "YYYYMMDD" as a 32 bit number, seems to work for all I have
needed. Sorts nicely as well.

 

[Bill Cunningham]

osmium wrote:

[snip]

Where does the linked list come from? I didn't say or imply anything
involving linked lists.

It sounded to me like what you was suggesting might be well done by a
linked list. There was no suggestion by you. I have trouble with that
algorithm.

17+5 = 22, the left digit changes from 1 to 2 because of a carry. You
said earlier you wanted to compute. Addition is about the
simplest computation there is. If you treat the 7 as an element of
an array, you must provide a carry if you want to add to the 7.

I'm not quite sure I understand. I will give this some thought though.

One of the better answers you were given last week was to use the
facilities in <time.h> but you chose to ignore that suggestion, for
reasons known only to you, and go your own way.

If I wanted to add yesterdays data today, would time.h be a very good
way to go? I keep track of friday's data. Sometimes I add it on saturdays.
Does this make sense?

If you decide to use a POSIX oriented solution, move your thread to
a news group appropriate for talking about POSIX, this is not such a
group.

Understood.

B

 

[James Waldby]

osmium wrote: ....

I'm not quite sure I understand. I will give this some thought
though.

Dates, times, or dates+times can be represented several different
ways in a computer. Choice of representation affects what is easy
to do with them.

With the date representation you mentioned (six characters or digits
for mmddyy) it is easy to do input and output but less easy to do
arithmetic (such as the amount of time between two dates, or what
day is 180 days after a date). To do such arithmetic, you may need
to compute carries; for example, "021811" + 14 days = "030311".

With date represented in an object of type time_t as defined by
the <time.h> header file it is easy to do date arithmetic (the
time_t type typically is like a 32-bit or 64-bit integer type)
and using routines mentioned in next paragraph it isn't difficult
to do input and output.

See <http://en.wikipedia.org/wiki/Time_t> for a time_t example.
Also read man pages for routines declared in <time.h>: clock(),
time(), difftime(), mktime(), strftime(), strptime(), gmtime(),
asctime(), ctime(), and reentrant versions of same. These
address the time-handling problems that people find it useful
to address, and using them may help avoid errors.

If I wanted to add yesterdays data today, would time.h be a very
good way to go? I keep track of friday's data. Sometimes I add
it on saturdays. Does this make sense?

....

 

[Jorgen Grahn]

Worse, why not use a POSIX structure compatible with functions like
localtime()/gmtime()/etc.

You'd have to be a bit careful to do that. A date isn't a time_t; the
same time_t can be different dates depending on your time zone.
You wouldn't want your software to break as soon as someone uses it in
New Zealand ...

I'd avoid local time, and let 2011-02-19 be represented by 2011-02-19
00:00:00 GMT. That should be workable.

/Jorgen

 

[Ian Collins]

You'd have to be a bit careful to do that. A date isn't a time_t; the
same time_t can be different dates depending on your time zone.
You wouldn't want your software to break as soon as someone uses it in
New Zealand ...

Well I live in NZ and coincidentally I did have some time/date code I
wrote on a trip to Europe fail when got home - a UTC time that was
Sunday in Spain was Monday here!