defining after execution
frank
{ /* symbolic link */
char targetName[PATH_SIZE + 1];
if (readlink (pathName, targetName, PATH_SIZE) != -1)
{
Has it always been legal C that you can define (I hope I got that verb
correct) targetName so? What happens if this snippet is executed serially?
Thanks for your comment.
--
frank
Seebs
> else if (S_ISLNK (entryInfo.st_mode))
> { /* symbolic link */
> char targetName[PATH_SIZE + 1];
> if (readlink (pathName, targetName, PATH_SIZE) != -1)
> {
> Has it always been legal C that you can define (I hope I got that verb
> correct) targetName so?
I don't understand. It's at the beginning of a block. What's the problem?
>What happens if this snippet is executed serially?
What do you mean by "serially"?
On some implementations, the surrounding code will have already secretly
allocated targetName. On others, upon entry into the block, targetName
will be allocated, and it will be deallocated when the block is exited.
-s
p.s.: Off-topic: There isn't a guaranteed predefined value for the
maximum length of a thing linked to, so if you want to be paranoid,
check to make sure that the value returned is less than the buffer
size, and if it wasn't, use a bigger buffer.
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Andrea Laforgia
wrote:
>Has it always been legal C that you can define (I hope I got that verb
>correct) targetName so? What happens if this snippet is executed serially?
Yes, it is perfectly legal to declare variables at the very start of a
compound statement. Variables like that are stored on the stack, so
there is no problem, if the code is executed serially. Lifetime and
scope of those variables are limited to the compound statement.
Kaz Kylheku
> { /* symbolic link */
> char targetName[PATH_SIZE + 1];
> if (readlink (pathName, targetName, PATH_SIZE) != -1)
> {
>
>
> Has it always been legal C that you can define (I hope I got that verb
> correct) targetName so?
You mean locally to a block? Yes.
> What happens if this snippet is executed serially?
Since it is not declared static, the array ceases to exist when the block
terminates, so if the block is executed repeatedly in a loop, the object comes
into existence and dies repeatedly.
How it is usually compiled is that these different instantiations
of the block are placed at the same memory location.
If there are multiple instantiations of the block at the
same time due to recursion, then they are different objects.
frank
Thanks all for replies. I wasn't understanding that it blips out of
existence as the block terminates.
I would think a person could also code this with a malloc and free, but
this seems tidy and safe enough for what it is. I'm not going to
recurse through it and memory is not scarce.
--
frank
Andrea Laforgia
wrote:
>I would think a person could also code this with a malloc and free, but
>this seems tidy and safe enough for what it is.
It depends on what you mean with "also" :)
malloc() and free() usually allocate and deallocate on the heap. When
they rely on the operating system's API, they are usually slower than
allocating/deallocating on the stack, for example.
frank
[x-posted to c.u.p.]
> -s
> p.s.: Off-topic: There isn't a guaranteed predefined value for the
> maximum length of a thing linked to, so if you want to be paranoid,
> check to make sure that the value returned is less than the buffer
> size, and if it wasn't, use a bigger buffer.
Determining the size of these buffers seems like a usual introduction to
unix. I started my little PATH_MAX hack at 100, was amazed at the
varieties of undefined behavior I brought forth on my machine, and now I
think 4096 might be a good number to start with on these buffers.
--
frank
Nobody
The correct answer for Unix (readlink() isn't in ANSI C) is to use
pathconf(path, _PC_PATH_MAX) or fpathconf(fd, _PC_PATH_MAX), where path or
fd identify the filesystem (the values can vary between filesystems, so
you might get a different result for /usr or /tmp than for the root
filesystem).
However:
1. [f]pathconf can return -1, indicating that there is no pre-determined
limit.
2. If the buffer isn't large enough, readlink() *doesn't* include a
terminating NUL byte.
So the safest approach is to malloc() a buffer, then call readlink() in a
loop, realloc()ing the buffer until the value returned from readlink() is
strictly less than (i.e. "<", *not* "<=") the the buffer size.
Seebs
> 2. If the buffer isn't large enough, readlink() *doesn't* include a
> terminating NUL byte.
Actually, so far as I can tell, it's not guaranteed to anyway.
> So the safest approach is to malloc() a buffer, then call readlink() in a
> loop, realloc()ing the buffer until the value returned from readlink() is
> strictly less than (i.e. "<", *not* "<=") the the buffer size.
Yeah. Annoying!
(followups to c.u.p.)
-s
Phred Phungus
> frank <fr...@example.invalid> writes:
>> Has it always been legal C that you can define (I hope I got that verb
>> correct) targetName so?
ok
> In C, one can not execute snippets at all, only statements.
>
Ein snippet kann von einfachen Anweisungen existieren, also ist Obige
irrig.
--
fred
Nick Keighley
body of your post
Subject: defining after execution
in this case it /is/ important because I haven't a clue what it means!
On 1 Feb, 20:48, frank <fr...@example.invalid> wrote:
> else if (S_ISLNK (entryInfo.st_mode))
> { /* symbolic link */
> char targetName[PATH_SIZE + 1];
> if (readlink (pathName, targetName, PATH_SIZE) != -1)
> {
>
> Has it always been legal C that you can define (I hope I got that verb
> correct) targetName so?
what's special about the definition of targetName? I can see a couple
of things. It's in an inner block, it's an array and it uses an
expression for the size of the array. So long as PATH_SIZE is a simple
constant this is all ok.
> What happens if this snippet is executed serially?
what? How do you execute something "serially". What other ways to
execute things are there?
General note its a good idea to use more complete examples when
posting code. With less implementation dependent clutter.
micropentium
Check Richard Stevens APUE charpter 2.5 Fig 2.15, it offers a good
solution to dynamically allocate space for this purpose.
Tim Rentsch
> frank <fr...@example.invalid> writes:
>>Has it always been legal C that you can define (I hope I got that verb
>>correct) targetName so? What happens if this snippet is executed serially?
>
> Yes.
>
>>correct) targetName so? What happens if this snippet is executed serially?
>
> In C, one can not execute snippets at all, only statements.
If you read section 6.12 of the latest draft (N1425), you
will see that C1X allows execution of snippets in
addition to statements.