Why is really an issue anyways? chmod should not be used too much anyways. 

The current fork/exec implementation is incorrect. Basically, it
re-implements system (). It is tricky to get it 100% correct. One
can take a look at system () source to see it him/herself.  I think
we should call chmod directly, rather than fix fork/exec.

> The current fork/exec implementation is incorrect.

How is it incorrect?  Since file could have spaces in it, using system is not useful at all and even harder to do the correct thing.  Really it does not use system because creating a string to use with system makes it even more incorrect than it is currently.

(In reply to comment #3)
> > The current fork/exec implementation is incorrect.
> 
> How is it incorrect?  Since file could have spaces in it, using system is not
> useful at all and even harder to do the correct thing.  Really it does not use
> system because creating a string to use with system makes it even more
> incorrect than it is currently.
> 

It should handle signal and check return from wait to match pid.

Here is one working implementation:

http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/posix/system.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=glibc

Another reason for using chmod() directly is that some systems cannot fork but still offer the function call.

I think the reason that one does the call instead of calling the library function is that one either needs to restrict the call or that one needs a fancy parser to support numeric values such as 0777 but also characters such as a+x for which the full pattern is [ugoa][+-=][rwxXst].

Created attachment 26305 [details]
Incomplete chmod parser

The attached chmod.c implements an incomplete chmod argument parser.
TODO:
- Check for the missing items and what should be supported
- Implement it in libgfortran and document the supported syntax.

Created attachment 26307 [details]
Improved version: POSIXly correct chmod as separate program

Attached: A "chmod" program, which takes a string and a file name and should act as a POSIX chmod program would do. Thus, it honors the "umask", allows for fancy combinations such as "g+w-r,a+x,-w,o=u,u+s,+t".

TODO:
- Convert this into libgfortran/intrinsic/chmod.c
- Write a fancy documentation for http://gcc.gnu.org/onlinedocs/gfortran/CHMOD.html which actually describes which modes are supported - and stats that the mode argument is in line with the "chmod utility" of POSIX (IEEE Std 1003.1-2001).

(In reply to comment #8)
> It honors the "umask", allows for fancy combinations such as
> "g+w-r,a+x,-w,o=u,u+s,+t".

Seemingly, I misread POSIX: For my program o=u sets "other" to the original permissions. By contrast, GNU chmod sets it to the last permission. For:
  umask 022; mkdir foo; chmod g+w-r,a+x,-w,o=u foo
the difference is whether other is r-x or rwx. In the code: Simply replace "old_mode" by "file_mode".

I have meanwhile also converted the fixed program into a libgfortran patch:
http://gcc.gnu.org/ml/fortran/2012-01/msg00126.html

Author: burnus
Date: Thu Jan 12 20:26:10 2012
New Revision: 183137

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183137
Log:
2012-01-12  Tobias Burnus  <burnus@net-b.de>

        PR fortran/36755
        * intrinsic.texi (CHMOD): Extend a bit and remove statement
        that /bin/chmod is called.

2012-01-12  Tobias Burnus  <burnus@net-b.de>

        PR fortran/36755
        * intrinsics/chmod.c (chmod_func): Replace call to /bin/chmod


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/intrinsic.texi
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/intrinsics/chmod.c

FIXED on the 4.7 trunk.

Thanks HJ for the report!