Bug 24886 - different character length in actual and formal argument not detected
Summary: different character length in actual and formal argument not detected
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid
Depends on: 26227
Blocks: Fortran_character
  Show dependency treegraph
 
Reported: 2005-11-16 00:12 UTC by Uttam Pawar
Modified: 2009-04-20 11:57 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-10-02 11:19:42


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Uttam Pawar 2005-11-16 00:12:28 UTC
Following code should print the runtime error, shouldn't it? This test is taken from http://ftp.cac.psu.edu/pub/ger/fortran/test

$ cat test.f90
        subroutine foo(y)
           character(len=20) :: y
           y = 'hello world'
        end

        program test
           character(len=10) :: x
           call foo(x)
           write(*,*) 'X=',x
           pause
        end

$ gfortran test.f90
$./a.out
X=hello worl
PAUSE
To resume execution, type go.  Other input will terminate the job.
go
RESUMED
Comment 1 Francois-Xavier Coudert 2005-11-16 15:00:32 UTC
What kind of runtime error would you think is appropriate? I don't see where the problem is.
Comment 2 Uttam Pawar 2005-11-16 17:33:49 UTC
Any error which indicates something like, "dummy argument defined to be larger than actual argument.
Comment 3 Andrew Pinski 2006-01-03 16:59:09 UTC
Not PPC specific.
Comment 4 Jerry DeLisle 2006-01-04 03:25:19 UTC
This is not a bug.  gfortran behavior is identical to ifort.
Comment 5 Paul Thomas 2006-01-11 09:07:40 UTC
(In reply to comment #4)
> This is not a bug.  gfortran behavior is identical to ifort.
> 
Actually, it is quite specifically NOT permitted by the standard. To quote 12.4.1.1:

"If a scalar dummy argument is of type default character, the length len of the dummy argument shall be less than or equal to the length of the actual argument.  The dummy argument becomes associated with the leftmost len characters of the actual argument.  If an array dummy argument is of type default character, the restriction on the length is for the entire array and not for each array element."

The reason for this is obvious enough; try writing beyond len and you will eventually get a seg fault.

Uttam is quite correct to pick this out as a bug, although I am not sure that we want a runtime error, except when -fbounds-check is active.  This could be implemented, with advantage in trans-expr(gfc_conv_function_call) by copying over some of the code from trans-array.c.

As it happens, in building a fix for PRs 20881, 23308 & 25710, I am about to add "same file" argument checking, which is why I encountered this PR.  It will fix Uttam's testcase but not the case where subroutine foo is truly external.
Comment 6 Uttam Pawar 2006-01-11 22:02:22 UTC
Subject: Re:  another runtime error goes undetected

On Wed, 2006-01-11 at 09:07 +0000, pault at gcc dot gnu dot org wrote:
> 
> ------- Comment #5 from pault at gcc dot gnu dot org  2006-01-11 09:07 -------
> (In reply to comment #4)
> > This is not a bug.  gfortran behavior is identical to ifort.
> > 
> Actually, it is quite specifically NOT permitted by the standard. To quote
> 12.4.1.1:
> 
> "If a scalar dummy argument is of type default character, the length len of the
> dummy argument shall be less than or equal to the length of the actual
> argument.  The dummy argument becomes associated with the leftmost len
> characters of the actual argument.  If an array dummy argument is of type
> default character, the restriction on the length is for the entire array and
> not for each array element."
> 
> The reason for this is obvious enough; try writing beyond len and you will
> eventually get a seg fault.
> 
> Uttam is quite correct to pick this out as a bug, although I am not sure that
> we want a runtime error, except when -fbounds-check is active.  This could be
> implemented, with advantage in trans-expr(gfc_conv_function_call) by copying
> over some of the code from trans-array.c.

Compile time check will be much better fix than the runtime.

> 
> As it happens, in building a fix for PRs 20881, 23308 & 25710, I am about to
> add "same file" argument checking, which is why I encountered this PR.  It will
> fix Uttam's testcase but not the case where subroutine foo is truly external.
> 

- Uttam
Comment 7 Tobias Burnus 2007-06-29 22:09:01 UTC
[Compile-time checking]

I think this was fixed a while ago - at least for contained procedures. If not it is then definitely fixed (for contained procedures) by my patch for PR30940:

"Character length of actual argument shorter than of dummy argument 'y' (10/20) at (1)"

To get it working with the original example, we need whole-file checking which is planned but not implemented.

Run-time checking would be nice too.
Comment 8 Daniel Kraft 2009-01-03 19:08:35 UTC
Runtime checking is PR 37746, BTW, I'm working on it and have a pending patch.  Would this fix this bug or should we wait for the whole-file checking?
Comment 9 Paul Thomas 2009-03-30 19:35:40 UTC
Subject: Bug 24886

Author: pault
Date: Mon Mar 30 19:35:14 2009
New Revision: 145314

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145314
Log:
2009-03-30  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/22571
	PR fortran/26227
	PR fortran/24886
	* symbol.c : Add gfc_global_ns_list.
	* decl.c (add_global_entry): Set the namespace ('ns') field.
	* gfortran.h : Add the resolved field to gfc_namespace. Add the
	namespace ('ns') field to gfc_gsymbol.  Add flag_whole_file to
	gfc_option_t.  Add the prototype for gfc_free_dt_list.
	* lang.opt : Add the whole-file option.
	* invoke.texi : Document the whole-file option.
	* resolve.c (resolve_global_procedure): If the fwhole-file
	option is set, reorder gsymbols to ensure that translation is
	in the right order.  Resolve the gsymbol's namespace if that
	has not occurred and then check interfaces.
	(resolve_function): Move call to resolve_global_procedure.
	(resolve_call): The same.
	(resolve_codes): Store the current labels_obstack.
	(gfc_resolve) : Return if the namespace is already resolved.
	trans-decl.c (gfc_get_extern_function_decl): If the whole_file
	option is selected, use the backend_decl of a gsymbol, if it is
	available.
	parse.c (add_global_procedure, add_global_program): If the flag
	whole-file is set, add the namespace to the gsymbol.
	(gfc_parse_file): On -fwhole-file, put procedure namespaces on
	the global namespace list.  Rearrange to do resolution of all
	the procedures in a file, followed by their translation.
	* options.c (gfc_init_options): Add -fwhole-file.
	(gfc_handle_option): The same.

2009-03-30  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/22571
	* gfortran.dg/whole_file_1.f90: New test.
	PR fortran/26227
	* gfortran.dg/whole_file_2.f90: New test.
	* gfortran.dg/whole_file_3.f90: New test.
	PR fortran/24886
	* gfortran.dg/whole_file_4.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/whole_file_1.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_2.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_3.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/lang.opt
    trunk/gcc/fortran/options.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog

Comment 10 Daniel Franke 2009-04-10 21:35:36 UTC
With the commit in comment #9 we get:

$> gfortran-svn -fwhole-file -Wall pr24886.f
[...]
pr24886.f:8.20:

           call foo(x)
                    1
Warning: Character length of actual argument shorter than of dummy argument 'y' (10/20) at (1)

Paul, can we close this one?
Comment 11 Paul Thomas 2009-04-20 11:57:41 UTC
(In reply to comment #10)

> Paul, can we close this one?
> 

Absolutely! It's done.

Paul