[Octave-bug-tracker] [bug #53654] [octave forge] (image) "rgb2gray.m shadows a core function" only under Windows, not under Linux

[Mike Miller]

Update of bug #53654 (project octave):

                  Status:               Need Info => Works For Me           
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #9:

I'll try to explain more fully, but yes, I think this is intentional behavior,
so closing.

When you run Octave normally (not from a build directory), it has a
compiled-in default path that includes all of the m-file subdirectories
(/opt/.../share/octave/4.3.91/m/audio, etc). You can see what this path is
with the pathdef function.

This core default path is the only set of directories that Octave checks with
the shadowing warning. If you run addpath('/foo') that contains a function
imcrop.m, you will not get a shadowing warning if you later load the image
package, because /foo is not in Octave's core default path.

If you run octave --no-init-path, the core default path is set to empty, there
is no builtin path. Any directories you add later, even if they would normally
have been on the default system path, are not treated like system directories
and the shadowing warning is not issued for any files in these paths.

When you use ./run-octave as a developer, octave runs with --no-init-path,
because the compiled-in directories may not exist yet if you haven't run 'make
install' yet. It uses the --path option to add all of the directories under
$sourcedir/scripts. These are not treated as system directories, so the shadow
warning is not issued.

This is analogous to GCC and system header files. GCC has a compiled-in
default set of include paths, like /usr/include. These are treated differently
from normal header files, for example certain warnings are disabled. If you
compile something with '-nostdinc -I/usr/include', then the header files in
/usr/include are not treated like system header files.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53654>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/