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

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

[Octave-bug-tracker] [bug #63480] Build error on Cygwin


From: anonymous
Subject: [Octave-bug-tracker] [bug #63480] Build error on Cygwin
Date: Fri, 9 Dec 2022 04:39:47 -0500 (EST)

Follow-up Comment #6, bug #63480 (project octave):

The release messages are supposed to be concise, not supposed to explain
every gory detail.  However, if you think it deserves a better explanation,
please feel free to reply with another text or (better for my lazy ass)
just send a git patch with different wording to the cygwin or cygwin-patches
ML.
I'm always open to suggestions.

In terms of the compatibility to 3.4.0, keep in mind that it's a rather
limited incompatibility.  We're basically talking about two problems:

- The name of an underlying internal datatype, indirectly exposed to
  userspace.  This only affects programming languages using name mangling
  *and* using the FILE type in public facing API. 

- Exposure of a difference in structure layout.  Three potential issues:

  - Size.  This is no issue.  First, FILE is used as pointer or ref in APIs,
    not as value.  Second, the size of __sFILE is the same as the size of
    __sFILE64 on LP64 systems.

  - Public macros.  No issue.  There's a small set of macros accessing a
    FILE * in stdio.h, utilizing the knowledge of the internal data layout
    of FILE.  These only access members of FILE which are the same size and
    the same offset in __sFILE as well as in __sFILE64.

  - Applications accessing FILE members.  This *should* be a no-no, given
    FILE is defined as an opaque type.  But even if, those apps typically
    access the same members as the macros in stdio.h, so they are unaffected.
    If there are still apps left at this point, they are hopelessly
    accessing internal implementation details and deserve a spanking.

That basically leaves the first point, the name mangling problem.

Last but not least, the short shelf life of 3.4.0 limits the number of
affected apps, too.  Hopefully.


Corinna


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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