bugGNU Octave - Bugs: bug #54052, the global statement clears...


bug #54052: the global statement clears previously assigned values

Submitted by:  Lars Kindermann <larskindermann>
Submitted on:  Mon 04 Jun 2018 07:23:35 AM UTC  
Category:  Interpreter Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sun 05 Aug 2018 05:24:11 PM UTC, comment #19:

Rik & John again:

I just rechecked and the change is due to something
else. The script that now fails is in a directory which
contains a globals.m file which declares the variable,
but this is not explicitly referenced in the code. How
this was found in the system before 16 Jun I do not know.
I just searched for the path, but could not find it.

Will look more when time permits.

Michael Godfrey <godfrey>
Project Member
Sun 05 Aug 2018 04:49:42 PM UTC, comment #18:

Rik and John,

I just found that there has been a change in the handling of global since 16 Jun. The change in this report could be the cause.

With a system build on 16 June I could reference a global
in a script which did not itself contain a global declaration.
Now that does not work. It is necessary to declare the global
in the script even though the variable is shown as existing
(as global) in a whos before invoking the script.

This change may be intentional and I would agree if it was
intended. Just thought it would be good to point out the

Michael Godfrey <godfrey>
Project Member
Tue 19 Jun 2018 03:59:53 PM UTC, comment #17:

Seems good to me. Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Tue 19 Jun 2018 01:38:56 PM UTC, comment #16:

I pushed the following changeset in an attempt to make the warnings clearer about what is happening:


Pushed on stable and merged to default.

John W. Eaton <jwe>
Project Administrator
Tue 19 Jun 2018 03:04:39 AM UTC, comment #15:

As a test case

In this case, x assumes the value of 12. This is correct, but there is no warning: "warning: global: global value overrides local value" for the second global statement.

For the first global statement, I agree that a more appropriate warning would be 'initialized to existing local variable'.

Rik <rik5>
Project Administrator
Sat 16 Jun 2018 02:40:06 PM UTC, comment #14:

Yes, if there is no global value for x defined, then

will make x global and preserve the local value. But if there is already a global x, then the same statements will make x global but not change the global value to match the local value. I see now that I got the warning message wrong. I think we can make this behavior somewhat clearer by issuing two different warnings:

for the first case, and

for the second.

I believe this behavior is compatible with Matlab's current behavior, but it only issues the one "local value may have changed" warning, which is kind of weird since it should be possible to warn when that actually does occur instead of just that it could.

John W. Eaton <jwe>
Project Administrator
Sat 16 Jun 2018 12:11:51 AM UTC, comment #13:

sorry, just realized that this is by design:
clear x will keep x in the global workspace.

Lars Kindermann <larskindermann>
Fri 15 Jun 2018 11:34:59 PM UTC, comment #12:

This introduced a strange behaviour

So despite of "clear x" the global value of x still persists somewhere...

Lars Kindermann <larskindermann>
Fri 15 Jun 2018 08:50:24 PM UTC, comment #11:

I pushed the following changeset on stable and merged with default:


John W. Eaton <jwe>
Project Administrator
Thu 14 Jun 2018 10:13:03 PM UTC, comment #10:

Matlab R2017b ( 64-bit (glnxa64)

does the same as Markus showed for R21016a

Michael Godfrey <godfrey>
Project Member
Thu 14 Jun 2018 07:18:42 PM UTC, comment #9:

I'll fix.

John W. Eaton <jwe>
Project Administrator
Thu 14 Jun 2018 05:30:45 PM UTC, comment #8:

Thanks, marking as confirmed, declaring a global variable should inherit its previous value if it was defined already as a non-global.

Mike Miller <mtmiller>
Project Administrator
Thu 14 Jun 2018 11:46:47 AM UTC, comment #7:

I Matlab R2016a:

Markus M├╝tzel <mmuetzel>
Project Member
Thu 14 Jun 2018 02:29:18 AM UTC, comment #6:

Michael - thanks, but the test that we need in Matlab is without the declarit function, what is the value of x after it is declared global, does it retain the value of the previous normal variable named x or is it reset to empty?

Mike Miller <mtmiller>
Project Administrator
Thu 14 Jun 2018 12:54:20 AM UTC, comment #5:

Matlab R2017b ( 64-bit (glnxa64)

First declarit has to be made a .m file (I accidentally
used declarit, not declereit). Then:

Michael Godfrey <godfrey>
Project Member
Wed 13 Jun 2018 09:07:35 PM UTC, comment #4:

This has been stalled for a week. Maybe the test code can be posted to the Octave-Maintainers list for someone with Matlab access to test.

Rik <rik5>
Project Administrator
Mon 04 Jun 2018 07:04:16 PM UTC, comment #3:

Can someone with access to Matlab test what the behavior is when a global is declared for the first time with the same name as a local variable that has already been initialized? It's unclear whether this is a Matlab compatibility issue until we see how Matlab actually behaves.

The way I read the docs, they are only describing what happens if you already have a global named "x" with a value, and a local variable in a different scope with its own different value. For example

This is the correct behavior and is Matlab compatible according to those docs. The remaining question is what happens if x has not yet been declared global in any scope.

Mike Miller <mtmiller>
Project Administrator
Mon 04 Jun 2018 06:53:04 PM UTC, comment #2:

Maybe I misunderstood the matlab doc. I don't have matlab to test it.

But a warning could be useful, indeed. Yesterday I spent at least an hour to locate a problem resulting from a late global in my code...

Lars Kindermann <larskindermann>
Mon 04 Jun 2018 05:02:38 PM UTC, comment #1:

From the Matlab documentation

> If a variable with the same name as the global variable already exists in the current workspace, MATLAB issues a warning and changes the value of that variable and its scope to match the global variable.

That does not explicitly describe what happens when the global variable is being defined for the first time. It seems open to interpretation whether the global variable gets the value of the existing variable, or whether the variable should be changed to inherit the default value of the global, i.e. [].

If this is actual intentional behavior in Matlab, it would be nice to find a reference saying that this can be relied on. Otherwise it's best to avoid writing code that does this.

Mike Miller <mtmiller>
Project Administrator
Mon 04 Jun 2018 07:23:35 AM UTC, original submission:

Matlab will retain the previous value instead but issue a warning, according to its documentation.

The Octave documentation does not specify what behaviour to expect.

In addition, I don't understand what the help

intents to explain. It would make some sense to me if the last x was uppercase, too?

Lars Kindermann <larskindermann>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by larskindermann (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-19 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2018-06-16 jwe StatusReady For Test => In Progress
    2018-06-15 jwe StatusConfirmed => Ready For Test
    2018-06-14 mtmiller StatusNeed Info => Confirmed
    2018-06-04 mtmiller Severity3 - Normal => 2 - Minor
        StatusNone => Need Info

    Back to the top

    Powered by Savane 3.4