octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #64599] Inconsistent warning ID for future tim


From: Linton Miller
Subject: [Octave-bug-tracker] [bug #64599] Inconsistent warning ID for future time stamp check in liboctave
Date: Fri, 25 Aug 2023 18:14:39 -0400 (EDT)

URL:
  <https://savannah.gnu.org/bugs/?64599>

                 Summary: Inconsistent warning ID for future time stamp check
in liboctave
                   Group: GNU Octave
               Submitter: linton
               Submitted: Fri 25 Aug 2023 10:14:37 PM UTC
                Category: Coding Style and Maintenance
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Unexpected Error or Warning
                  Status: None
             Assigned to: None
         Originator Name: Linton Miller
        Originator Email: 
             Open/Closed: Open
                 Release: stable
         Discussion Lock: Any
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Fri 25 Aug 2023 10:14:37 PM UTC By: Linton Miller <linton>
There is a _very_ minor inconsistency in the ID used for the "time stamp on
file X is in the future" warning between the interpreter and dynamic library
functions.

libinterp/parse-tree/oct-parse.yy

  warning_with_id ("Octave:future-time-stamp",
                   "time stamp for '%s' is in the future", nm.c_str ())


liboctave/util/oct-shlib.cc

    (*current_liboctave_warning_with_id_handler)
      ("Octave:warn-future-time-stamp",
       "timestamp on file %s is in the future", m_file.c_str ());


These are the same check, just done in different contexts, so my expectation
is they should both use the same warning ID. Given the standard naming scheme,
that would be Octave:future-time-stamp.

Thus the fix would be to change oct-shlib.cc to use that. I will attach a
patch doing so.








    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64599>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]