strcat for pointer??

[monkeyboi]

i want to append some text to a pointer variable but the strcat won't let me, it works for array var tho...

anyway here is and example

char *text = "text for the pointer";
char textarry[444] = "text for the char array";

strcat(text, "new text to append"); // this one doesn't work

strcat(textarray, "new text to append"); // this one works fine...


can any1 tell me y??

and one question... how can u find out if a path is a file or a directory

like if the user enter /home/me/hello
how can i check that in C where it's a folder or a file???

thx alot!
:)

[mingshun]

Originally posted by monkeyboi
i want to append some text to a pointer variable but the strcat won't let me, it works for array var tho...

anyway here is and example

char *text = "text for the pointer";
char textarry[444] = "text for the char array";

strcat(text, "new text to append"); // this one doesn't work

strcat(textarray, "new text to append"); // this one works fine...

can any1 tell me y??


Simply because when you do a
char * string = "xxx";
, you have actually declared this char * as a constant. A constant ofcourse can't be altered. On the other hand, char [] isn't a constant char * and that is why you are free to change it.



and one question... how can u find out if a path is a file or a directory

like if the user enter /home/me/hello
how can i check that in C where it's a folder or a file???

thx alot!
:)

Easiest way that I can think of ... Make use the system call execlp.

execlp ("ls","ls -F /home/me/hello", 0);

I didn't compile the above but I think this should work.

[bwkaz]

Originally posted by mingshun
execlp ("ls","ls -F /home/me/hello", 0); Err, yes, that will work, but it will halt your program at the point you call exec, and start up the ls program there. Probably not what you want...

Take a look at the man page for stat().

man 2 stat

Specifically, the The following flags are defined for the st_mode field: part of that man page.

[monkeyboi]

ok you'r saying
char *text = "sdkfjsdlkfsld"; // constant

now i do
char *text;

and add the text at a later time.. but that still doesn't work..
i even malloc() enough memory for the job too....

with char textarry[444];// it works fine but i don't like to use array for text...:)


thx for the help...

[Energon]

It depends on how you're assigning the text. Doing this:


char* text = malloc(64*sizeof(char));
text = "some text";


Won't work, and in fact is a memory leak. If you look at the addresses of text before and after the second assignment, their different. So if you're not doing so already, the proper way is:


char* text = malloc(64*sizeof(char));
strncpy(text, "some text", 64);


That will work, assuming text has enough space to strcat() onto (the other really important issue). And in fact, it's best to use strncat() if you can.

But if you can use an array, it's probably better since calls to malloc and free are needlessly slow if you can live without them (and they make memory leaks harder to avoid).

Hope that helps.

[mingshun]

Originally posted by monkeyboi

with char textarry[444];// it works fine but i don't like to use array for text...:)


Besides what Energon had said;
I think you don't like array because you probably feel that specifying the size at the beginning somehow restricts you. To be fair, a string don't normally come in enormous size. On top of that, anyhow dynamically allocating memory to a char * is much more error prone than declaring a char array. So do start to change your habit and overcome the fear of array now! :)

[monkeyboi]

thank you all....

i guess i need to give array a chance ahahha...:)

[M3_!ha^]

Originally posted by bwkaz
Err, yes, that will work, but it will halt your program at the point you call exec, and start up the ls program there. Probably not what you want... Then fork() beforehand. Then setup a message queue, and have the child process pass it back when it's finished. As long as the message struct isn't larger than 8192 bytes.

[Energon]

Originally posted by M3_!ha^
Then fork() beforehand. Then setup a message queue, and have the child process pass it back when it's finished. As long as the message struct isn't larger than 8192 bytes.

That is soooo overcomplicating things...

[bwkaz]

Especially when you can just stat() it yourself... and not worry about any of that.

I've done that with one or two things; it's really not pretty.

[M3_!ha^]

Originally posted by Energon
That is soooo overcomplicating things... OK... fair enough....

How about fork()'ing and then setting up shared memory. After the child process has written the appropriate data... have it send a user signal back to the parent process which has an interrupt handler ready to process the signal.

[Energon]

See... now you're thinking KISS. It feels so much better, doesn't it? ;)

[mingshun]

Originally posted by Energon
See... now you're thinking KISS. It feels so much better, doesn't it? ;)

Agree with Energon.
Sorry for posting such a crappy execlp solution.


M3_!ha^:
Shared Memories, message queues, signals ... are all OS dependent. We should try to avoid using them in general programming unless we are doing something OS-specific.

[bwkaz]

mingshun: Of course, stat(), being a system call, is also OS-dependent, which sort of invalidates that reasoning behind not using fork() and whatnot.

But regardless of portability, fork(), exec(), shmget(), it's all really, really complicated. I know it will work, eventually. Maybe. But when you can just call stat() once, and take a look at the struct that it "returns", using one macro on one of its members, there is absolutely no reason to start fork()ing for anything.

Exactly. KISS.

[M3_!ha^]

Originally posted by mingshun
M3_!ha^:
Shared Memories, message queues, signals ... are all OS dependent. We should try to avoid using them in general programming unless we are doing something OS-specific. Programming for absolute portability just means adhering to a standard. But geez, take POSIX for example, Windows doesn't support POSIX threads... does that mean that I can't program with threads?

Shared memories, message queues, signals, <insert IPC here>, etc... are all great conveniences to learn about and have in your arsenal.

You are correct about portability. But even compilers for the same specific OSs have their nuances between them (sorry... I'm getting off track). Just about every developed OS has some sort of communications package for processes. Learning the concepts are the important part... syntax and the means of implementation is the only real difference. Considering ANYONE can learn syntax, I'd say that's a weak statement.

[bwkaz]

Yes, but shared memory, fork, exec, those are the wrong tool for something this simple. Yes, they may work. And they do have their uses, which means they should be learned. But they're way too complicated for this; that's what I at least am saying.

You do not need another process that effectively is only calling stat() for you (since that's the only info from it you use), when you can just call stat() yourself!

[M3_!ha^]

Complicated... no.
Over-kill... yes.

I agree, a stat() would be the better choice in this specific instance. If you read my first two suggestions closer, I was attempting to score sarcasm points... but I guess my attempts weren't recieved. :rolleyes:

I have a pet peeve of people saying fundamental things are "complicated." No system calls (for instance) are really that complicated, they just take time to understand all the available options and possible parameters.

[Energon]

Complicated - 1. Consisting of parts intricately combined.


Word to that...

EDIT - but I found your sarcasm in the second post to be much amusing... :D

[bwkaz]

Originally posted by M3_!ha^
Complicated... no.
Over-kill... yes. OK, I see what you mean. Right, it may not be complicated in that you have to keep track of a ton of stuff, and inter-weave (is that even a word?) it all. I did mean "overkill" more than "complicated". Should have thought more...

:o

And I do see the sarcasm now. Although I will admit that I'm lame if I require it to be pointed out... ah well. ;)

[mingshun]

Originally posted by bwkaz
mingshun: Of course, stat(), being a system call, is also OS-dependent, which sort of invalidates that reasoning behind not using fork() and whatnot.


Okay, pardon my ignorance :p


But regardless of portability, fork(), exec(), shmget(), it's all really, really complicated.
Exactly. KISS.

I know what you mean. This is just like killing a chicken with a gun.

M3_!ha^:
And I think system calls can be extremely complicated because sometimes, it does not only boil down to coding. You need to know the implications behind them for debugging, i.e: fork will mean parent and child running in different address spaces, running in parallel, deadlock may occur, ...

Our poor poster just wants to know the status of the file. He doesn't need to go through all these to get his job done.

[M3_!ha^]

Originally posted by mingshun
M3_!ha^:
And I think system calls can be extremely complicated because sometimes, it does not only boil down to coding. You need to know the implications behind them for debugging, i.e: fork will mean parent and child running in different address spaces, running in parallel, deadlock may occur, ... Please read my above post.

You shouldn't be against using fork() (for example) because it's tougher to debug. Sure, it creates a new descriptor table, a copy of all variables for the child, etc... but, you'd be passing on an incredibly powerful tool. As for being "complicated"... I think that's just an excuse people use for not wanting to do a liitle research. I could explain fork() to a beginning C programmer (who understands basic OS organization and IPC fundamentals), and have them using it correctly within 45 minutes tops.