zmq_msg_t is not used internally, it is only for external use, just to
allocate the memory, internally msg_t is used, which should be the same
size.
So if the allocated memory is the same size as msg_t, it doesn't matter how
you allocate that memory.
So when you allocate zmq_msg_t internally this memory is used as msg_t. You
can also just allocate a byte array at size of 64 and it will work as well.
On Thu, Feb 18, 2016 at 3:57 PM, Luca Boccassi <luca.bocca...@gmail.com>
wrote:
> Yes, the size is the same, but if the alignment changes then it's not
> binary compatible I'm afraid. It is common for zmq_msg_t to be
> allocated on the application's stack and then passed by reference to
> the library to be manipulated. Given the new version imposes stricter
> constraints on the compiler, I'm told that on x86 it will (probably)
> work fine. But on other architectures it might not, as the old library
> (and applications) and the new library will have been built under
> different assumptions and constraints.
>
> I'm not in any way familiar with SPARC, so I can only desume from the
> inline comment that having a pointer will force the compiler to make
> different (and stricter) choices regarding alignment.
>
> Kind regards,
> Luca Boccassi
>
> On 18 February 2016 at 13:40, Doron Somech <somdo...@gmail.com> wrote:
> > So this doesn't change the size of the zmq_msg_t (at it is a union), so
> > internally there is no difference.
> > Anyway I'm not sure what is the reason for this extra pointer.
> >
> > On Thu, Feb 18, 2016 at 2:06 PM, Luca Boccassi <luca.bocca...@gmail.com>
> > wrote:
> >>
> >> Cool stuff!
> >>
> >> I was having a look at the changes in the public headers between 4.1
> >> and master, and there _might_ be a backward-incompatible ABI change
> >> between 4.1 and 4.2:
> >>
> >> -typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
> >> +/* union here ensures correct alignment on architectures that require
> it,
> >> e.g.
> >> + * SPARC
> >> + */
> >> +typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;
> >>
> >> Given zmq_msg_t is very often allocated on the calling application's
> >> stack, having a different alignment between the application and the
> >> library might break stuff if the library is making assumptions based
> >> on it. Haven't delved deeper into it, does anyone have a better
> >> insight in how zmq_msg_t is handled internally?
> >>
> >> Kind regards,
> >> Luca Boccassi
> >>
> >> On 18 February 2016 at 09:12, Pieter Hintjens <p...@imatix.com> wrote:
> >> > libzmq versioning is unchanged for years. There's a 4.1 stable fork
> >> > that we apply fixes to, and will make one or two more releases of.
> >> > There's 4.2 arriving on master, with a mix of stable API and new draft
> >> > API. One thing we will do in 4.2 is clearly mark the draft API as
> >> > such, and perhaps not build it by default, from source packages. We're
> >> > using the same approach in CZMQ and other projects now.
> >> >
> >> > The goal with this is to allow shipment of the current master without
> >> > having 100% stability on the API. There are things we know we'll need
> >> > to refine and improve.
> >> >
> >> > -Pieter
> >> >
> >> > On Thu, Feb 18, 2016 at 12:04 AM, Mario Steinhoff
> >> > <steinhoff.ma...@gmail.com> wrote:
> >> >> So my question about the state of zmq versioning drifted in some kind
> >> >> of we-need-more-automation-for-the-docs initiative. Awesome :)
> >> >>
> >> >> I'd love to help with it but I am already busy with the jzmq stuff
> for
> >> >> now.
> >> >>
> >> >> But the first question is still unanswered:
> >> >>
> >> >>> With all this, whats the current status on libzmq versioning?
> >> >>
> >> >> Or does no answer mean that all my assumptions were correct?
> >> >>
> >> >> 2016-02-17 18:48 GMT+01:00 Pieter Hintjens <p...@imatix.com>:
> >> >>> We could use this, yes.
> >> >>>
> >> >>> Volunteers? :)
> >> >>>
> >> >>> On Wed, Feb 17, 2016 at 3:45 PM, Michel Pelletier
> >> >>> <pelletier.mic...@gmail.com> wrote:
> >> >>>> Read the docs is fantastic, I used it for pyczmq and it works
> great.
> >> >>>> Also
> >> >>>> it's not just software or a hosting service, the author (a local
> here
> >> >>>> in my
> >> >>>> neck of the woods) hosts "write the docs" conferences focusing on
> >> >>>> writing
> >> >>>> and producing good documentation:
> >> >>>>
> >> >>>> http://www.writethedocs.org/
> >> >>>>
> >> >>>> All together it's a powerful documentation ecosystem.
> >> >>>>
> >> >>>> -Michel
> >> >>>>
> >> >>>> On Wed, Feb 17, 2016 at 6:17 AM, Pieter Hintjens <p...@imatix.com>
> >> >>>> wrote:
> >> >>>>>
> >> >>>>> We have generators of various kinds: gitdown, mkman, which
> zproject
> >> >>>>> uses/plugs into. The commonality is text files that turn into man
> >> >>>>> pages and then various other formats that can be sent anywhere. I
> >> >>>>> don't think we need to *standardise* so much as decide on a
> format,
> >> >>>>> a
> >> >>>>> host, and a safe way to upload after successful CI builds. We can
> >> >>>>> have
> >> >>>>> many of these.
> >> >>>>>
> >> >>>>> On Wed, Feb 17, 2016 at 12:05 PM, Arnaud Loonstra
> >> >>>>> <arn...@sphaero.org>
> >> >>>>> wrote:
> >> >>>>> > Perhaps we can standardise on this? Perhaps even include some
> >> >>>>> > generators for it in zproject?
> >> >>>>> > I was starting to use Sphinx for Pyre as well. Now using it for
> >> >>>>> > multiple projects. I'm not familiar with how it works with other
> >> >>>>> > languages but for Python it's great.
> >> >>>>> >
> >> >>>>> > On 2016-02-17 10:39, Doron Somech wrote:
> >> >>>>> >> Take a look at readthedocs.org [9], it is what NetMQ is using
> and
> >> >>>>> >> completely automated. You manage the docs in the git
> repository.
> >> >>>>> >>
> >> >>>>> >> On Wed, Feb 17, 2016 at 10:41 AM, Pieter Hintjens <
> p...@imatix.com
> >> >>>>> >> [10]>
> >> >>>>> >> wrote:
> >> >>>>> >>
> >> >>>>> >>> Hmm, the tools we use to build the online docs are old and
> >> >>>>> >>> creaky,
> >> >>>>> >>> and
> >> >>>>> >>> date from long before we had neat CI automation. Meaning, we
> >> >>>>> >>> update
> >> >>>>> >>> the api site manually.
> >> >>>>> >>>
> >> >>>>> >>> Im doing that now. I think its time we look at pushing this
> >> >>>>> >>> directly
> >> >>>>> >>> to github pages, from Travis.
> >> >>>>> >>>
> >> >>>>> >>> On Wed, Feb 17, 2016 at 12:47 AM, Mario Steinhoff
> >> >>>>> >>> <steinhoff.ma...@gmail.com [1]> wrote:
> >> >>>>> >>> > Hi everyone,
> >> >>>>> >>> >
> >> >>>>> >>> > I am a bit confused about the available information on
> libzmq
> >> >>>>> >>> versions.
> >> >>>>> >>> >
> >> >>>>> >>> > The page at api.zeromq.org [2] says that we have:
> >> >>>>> >>> >
> >> >>>>> >>> > - 4.2 (master)
> >> >>>>> >>> > - 4.1 (rc)
> >> >>>>> >>> > - 4.0 (stable)
> >> >>>>> >>> > - 3.2 (stable)
> >> >>>>> >>> >
> >> >>>>> >>> > On the download page 4.0 is missing:
> >> >>>>> >>> >
> >> >>>>> >>> > - a version-less master which "should be stable almost all
> the
> >> >>>>> >>> time" (4.2?)
> >> >>>>> >>> > - 4.1.4 ("stable")
> >> >>>>> >>> > - 3.2.5 ("legacy stable")
> >> >>>>> >>> >
> >> >>>>> >>> > In libzmq, the NEWS file on master seems to be outdated
> (last
> >> >>>>> >>> update
> >> >>>>> >>> > in 2014). The doc folder in libzmq seems to be maintained
> but
> >> >>>>> >>> > not
> >> >>>>> >>> in
> >> >>>>> >>> > sync with api.zeromq.org [3] (I checked today and some
> changes
> >> >>>>> >>> from the
> >> >>>>> >>> > last commit in that folder are not present on the site).
> >> >>>>> >>> >
> >> >>>>> >>> > There are also maintained stabilization forks as per C4.1
> for
> >> >>>>> >>> libzmq,
> >> >>>>> >>> > e.g. zeromq4-x (which contains 4.0?), 4-1, and 3-x (which
> >> >>>>> >>> contains
> >> >>>>> >>> > 3.2?).
> >> >>>>> >>> >
> >> >>>>> >>> > And then there is this article: http://hintjens.com/blog:85
> >> >>>>> >>> > [4]
> >> >>>>> >>> which
> >> >>>>> >>> > suggests in a very compelling way that software versions
> suck
> >> >>>>> >>> > and
> >> >>>>> >>> to
> >> >>>>> >>> > ditch them altogether (yes I agree) but I cant find those
> >> >>>>> >>> > SBOMs
> >> >>>>> >>> > anywhere so I assume that experiment did not went very far.
> >> >>>>> >>> >
> >> >>>>> >>> > With all this, whats the current status on libzmq
> versioning?
> >> >>>>> >>> >
> >> >>>>> >>> > Am I understanding right that:
> >> >>>>> >>> >
> >> >>>>> >>> > - The libzmq repository is always the latest and greatest,
> and
> >> >>>>> >>> 4.2
> >> >>>>> >>> > looks like the last version Ill ever need™, its always
> stable
> >> >>>>> >>> and
> >> >>>>> >>> > follows the raw-draft-stable-deprecated process so its also
> >> >>>>> >>> always
> >> >>>>> >>> > backwards compatible.
> >> >>>>> >>> >
> >> >>>>> >>> > - Stable releases are maintained for 3.2, 4.0, and 4.1 and
> >> >>>>> >>> sometimes
> >> >>>>> >>> > bugfixes get backported from 4.2.
> >> >>>>> >>> >
> >> >>>>> >>> > - Release notes are only maintained for stable releases?
> >> >>>>> >>> >
> >> >>>>> >>> > Is the outdated API site a bug or a feature? I am currently
> >> >>>>> >>> > using
> >> >>>>> >>> the
> >> >>>>> >>> > text files in doc/ but I like to look at the fancy ZMQ logo
> >> >>>>> >>> > when
> >> >>>>> >>> I
> >> >>>>> >>> > browse the API reference :-)
> >> >>>>> >>> >
> >> >>>>> >>> > Cheers
> >> >>>>> >>> > Mario
> >> >>>>> >>> > _______________________________________________
> >> >>>>> >>> > zeromq-dev mailing list
> >> >>>>> >>> > zeromq-dev@lists.zeromq.org [5]
> >> >>>>> >>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev [6]
> >> >>>>> >>> _______________________________________________
> >> >>>>> >>> zeromq-dev mailing list
> >> >>>>> >>> zeromq-dev@lists.zeromq.org [7]
> >> >>>>> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev [8]
> >> >>>>> >>
> >> >>>>> >>
> >> >>>>> >>
> >> >>>>> >> Links:
> >> >>>>> >> ------
> >> >>>>> >> [1] mailto:steinhoff.ma...@gmail.com
> >> >>>>> >> [2] http://api.zeromq.org
> >> >>>>> >> [3] http://api.zeromq.org
> >> >>>>> >> [4] http://hintjens.com/blog:85
> >> >>>>> >> [5] mailto:zeromq-dev@lists.zeromq.org
> >> >>>>> >> [6] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >>>>> >> [7] mailto:zeromq-dev@lists.zeromq.org
> >> >>>>> >> [8] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >>>>> >> [9] http://readthedocs.org
> >> >>>>> >> [10] mailto:p...@imatix.com
> >> >>>>> >
> >> >>>>> > _______________________________________________
> >> >>>>> > zeromq-dev mailing list
> >> >>>>> > zeromq-dev@lists.zeromq.org
> >> >>>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >>>>> _______________________________________________
> >> >>>>> zeromq-dev mailing list
> >> >>>>> zeromq-dev@lists.zeromq.org
> >> >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> zeromq-dev mailing list
> >> >>>> zeromq-dev@lists.zeromq.org
> >> >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >>>>
> >> >>> _______________________________________________
> >> >>> zeromq-dev mailing list
> >> >>> zeromq-dev@lists.zeromq.org
> >> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Mario Steinhoff
> >> >> https://github.com/msteinhoff
> >> >> https://twitter.com/msteinhofff
> >> >> T: +49 173 7265158
> >> >> In der Gelpe 79
> >> >> 42349 Wuppertal
> >> >> _______________________________________________
> >> >> zeromq-dev mailing list
> >> >> zeromq-dev@lists.zeromq.org
> >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> > _______________________________________________
> >> > zeromq-dev mailing list
> >> > zeromq-dev@lists.zeromq.org
> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev@lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
