in reply to Re: Re: Re: Re: Re: Re: Declaring variables - is it legal to do this?
in thread Declaring variables - is it legal to do this?

You were talking about system dependencies:

Well since perl is written in C, there could be unspecified behaviours in Perl itself (ie. having different valid results for the same code with different platforms),

Platform and system means almost the same here, doesn't it?

(and it doesn't depend on C at all, there's no select in C).

What do you mean here "not in C"? Select is a system call, so what it does with the time is an issue of the OS kernel, but the restarting of system calls after signals is handled by the C library IIRC. (Or doesn't it, does the kernel restart syscalls if you say so with sigaction, maybe libc just sets the default behaviour to what you want, I'm not sure).

  • Comment on Re: Re: Re: Re: Re: Re: Re: Declaring variables - is it legal to do this?

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: Declaring variables - is it legal to do this?
by theon (Beadle) on May 16, 2004 at 18:20 UTC
    Well I don't expect functions whose purpose is to use a system call/function to be completely system-independant. I had in mind the "core language" only, like the original question in this thread.

    There's no select in C because it's actually in POSIX/Unix-related libraries, it's not in standard C (C89, C99...) It may be in the same library on your system though, if this library implements both C library and Unix functions.

    There are unspecified behaviours in C which really depend on the core language, not the library. For example, in y = f(x) + g(x), you don't know if f is called before g or not, I think it's specified by a compiler, but it's not in the standard. Here I see people say "Try it to see what it's doing", so I suppose in such a case, there's no unspecified behaviour in Perl, because in C testing is not enough to know (f is called before g on Sparc with gcc, g is called before f on x86 with gcc).