Skip to content
Snippets Groups Projects
  1. Mar 17, 2023
  2. Jan 09, 2023
  3. Jan 06, 2023
  4. Jan 05, 2023
  5. Jan 04, 2023
  6. Nov 15, 2022
    • Jonathan Schöbel's avatar
      API change: error -> status for exception handling · 0e0fa194
      Jonathan Schöbel authored
      Instead of the trivial structure SH_Error, SH_Status is used. The name
      was chosen, because error/status is set independently whether an error
      has occurred. Beside the error type, it also contains the associated
      errno and an error message. The error message is also printed, when it
      is set. Generating error messages with variadic arguments is now also
      supported.
      There are also macros to check for a set status.
      
      The exception handling was removed for the *_free methods, because they
      can't fail predictably during runtime.
      
      Unfortunately the compiler reports, that inside the macro set_status
      printf may be called with NULL [printf (NULL)], although, this is
      explicitly debarred.
      0e0fa194
  7. Oct 17, 2022
    • Jonathan Schöbel's avatar
      setup library (make & API) · f86bd5cf
      Jonathan Schöbel authored
      The make process was restructured to create a library. For this libtool
      is used to provide both static and dynamic linking. Also header
      inclusion guards were introduced, to prevent clients of the library to
      include some single file without including others. The types were
      exported with forward declarations for better abstraction. When
      compiling the library, the macro LIB_SEFHT_COMPILATION is defined and
      symbol declarations are exported fully. For compiling the tests this
      macro is also defined, as the tests not only tests the API, but also the
      internal state, because a lot of errors couldn't be detected otherwise.
      f86bd5cf
  8. Jun 21, 2022
    • Jonathan Schöbel's avatar
      error handling added · 6a592b8d
      Jonathan Schöbel authored
      Error handling is done by passing an Error structure as inout parameter
      to functions that can fail on runtime predictable. This parameter is
      always the last one. Methods, where this is not the case, doesn't have an
      error parameter.
      When an Error is detected, also an ERROR is passed to the log. Because
      this isn't implemented yet, it is replaced by a nop.
      The macro EXIT becomes now useless. It was used earlier in case of an
      error, to terminate the program in the first place. This behaviour is not
      userfriendly, but it can't be decided on the library's side, whether
      there is an option to inform the user, something must be cleaned up or
      even that recovering is possible at all.
      Often these recognized errors are a non-working malloc or an over-/underflow.
      
      Error handling can be ignored by the caller by passing NULL to the Error
      parameter. Whether an error had occured, is also always possible to be
      determined, by examining the return value. If the error occours in a
      function returning a pointer, NULL will be returned. If it returns an value,
      a special error value of that type is returned, i.e. PAGE_ERR in
      SH_Data_register_page. If the return type would be void, a boolean is returned,
      which tells, whether the method has succeeded.
      (False means, that an error has occured.)
      
      The error may have occured in an intern method and is passed upwards (the stack).
      Internally errors are handled by an enum, but this must be considered an
      implementation detail and can be changed in later versions.
      It is in the responsibility of the caller to recover gracefully. It has
      to be assumed that the requested operation have neither worked, nor
      actually took place. Those the operation can be retried (hopefully).
      6a592b8d
  9. Jun 20, 2022
Loading