Uh, hey guys. This is probably for the 'higher-ups' in programming..

I'm tgrying to do a stat() on /proc/empeg_notify. Trying to get the 'st_atime', 'st_mtime', and 'st_ctime' of the file. The number I'm getting back is a unix-timestamp (I'm assuming).. Now, I am havin' three small questions..

1. When I make my small program, I get the error: warning: assignment makes pointer from integer without a cast on the line: if ((finfo = malloc(sizeof(struct stat))) == NULL). Where 'finfo' is a 'struct stat *finfo'. Now, that line compiles perfectly when I'm NOT using the empeg toolkit (normal RedHat). Is this warning anything to be concerned about? Did I get something wrong somewhere?

2. When the program runs, I get a timestamp of '1056390254', which seems to equivate to "Jun 23rd 2003, 17:44:14 GMT". The date on my 'file' is Jun 24 02:22. I'd SAY that the timestamp matches the date on the file, IF the minutes and seconds matched. But they don't.

3. The timestamps aren't getting updated when the data IN the 'file' is changed, or I write something to the 'file'. I'm guessing that either: 1. This is because of #1 above, and the timestamp in #2 is fake, or 2. /proc 'files' can't have any data on them pulled thru the 'stat()' function.

Comments? Answers? Any info'd be appreciated. Never delt with having to deal with the proc filesys before..

Me.

if ((finfo = malloc(sizeof(struct stat))) == NULL)

Try this:
if ((finfo = (void *)malloc(sizeof(struct stat))) == NULL)

The warning, in this case, is harmless.

As for timestamps on /proc/ "files", you have to keep in mind (or you have to know, first) that there are NO files under /proc/.

What you see there that look like files, are not really files. When you try and read from them, what happens is that the kernel generates the data on-the-fly, each time you read from them.

Otherwise, the data does not exist, and therefore cannot have a timestamp.

The data in those "files" is generated on-demand, whenever they are read.

Got it?

Hmm.. Okay, yeah, now I understand. I did not know that about the /proc system, and that clears it up. For obvious reasons, then, I don't even NEED that statement, but thanks.

Which, then, I guess, leads to a different question.

Other than always looking at the 'contents' of 'empeg_notify', is there a different way one could tell (other than listening, heh.) that the 'current song playing' has changed? That's my /ultimate' goal..

Many thanks!
Mike.

In reply to:

---

When I make my small program, I get the error: warning: assignment makes pointer from integer without a cast on the line: if ((finfo = malloc(sizeof(struct stat))) == NULL).

---

That's a danger sign that you're missing a declaration for malloc() and the compiler is assuming a declaration of "int malloc(...)" which is not what you want. Make sure you #include <stdlib.h> in your program. Don't be tempted to hide the warning by casting the result of malloc to, say, void*, as this can mask problems in your code.

(I'd guess that the reason it compiles okay on Red Hat is that another include file, perhaps <string.h> is pulling in <stdlib.h> for you, but the empeg build environment does not. Always include it explicitly.)

As to the modtimes on /proc inodes, I think it's up to each device what it returns. I'd guess that in this case, the empeg_notify device just returns the current time, rather than storing the last-change time somewhere. I think one could make a small kernel change to do what you want... Also, be sure you're not being confused by the time-zone offset, if you're not working in UTC - user commands like ls will show times adjusted by TZ, whereas the timestamp value is in UTC.

Instead of allocating the space for struct stat (and presumably free-ing it later on in the same function), why not declare it on the stack. I hardly ever see any application that actually passes the full 'struct stat' around, it is typically only used to check some timestamp or extract some specific fields and return.

{
struct stat finfo;
stat(..., &finfo);
return (finfo.st_mtime > time);
}