1065055 - Dont assume endian.h defines only __BYTE_ORDER

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Landry Breuil (:gaston)]

Funnily, in bug #714312 i added support to detect machine/endian.h on BSD systems to detect endianness.. time passed, and OpenBSD recently gained an endian.h include, but it does *not* define __BYTE_ORDER (cf http://marc.info/?l=openbsd-cvs&m=140518236422542&w=2) but only BYTE_ORDER.

I've been told (and accordingly to http://austingroupbugs.net/view.php?id=162#c665) that posix is in the process of standardizing endian.h, assuming that it defines BYTE_ORDER. So i think jscpucfg.h should also handle the case where endian.h is here, and do its #ifdef dance also for BYTE_ORDER. Diff in a few.

Comment 1

[Landry Breuil (:gaston)]

Attachment: also define IS_{LITTLE,BIG}_ENDIAN according to BYTE_ORDER

If it is the way to go, could use a backport to aurora/beta... i will also push it to try. who knows what dragons can live there..

Comment 2

[Landry Breuil (:gaston)]

https://tbpl.mozilla.org/?tree=Try&rev=61c982ce7e60

Comment 3

[Landry Breuil (:gaston)]

Example log of a failing build: http://buildbot.rhaalovely.net/builders/mozilla-aurora-sparc64/builds/530/steps/build/logs/stdio

Comment 4

[Nicholas Nethercote [inactive]]

Comment on attachment 8486631 [details] [diff] [review]
also define IS_{LITTLE,BIG}_ENDIAN according to BYTE_ORDER

Review of attachment 8486631 [details] [diff] [review]:
-----------------------------------------------------------------

A brief comment explaining the two cases would be nice. Thanks.

Comment 5

[Landry Breuil (:gaston)]

Some builds are burning on try, and i cant make any sense of the failures.. as for the comment, i suppose you prefer it directly within jscpucfg.h, explaining the previous status quo with __BYTE_ORDER and the direction posix goes ?

Comment 6

[Nicholas Nethercote [inactive]]

(In reply to Landry Breuil (:gaston) from comment #5)
> Some builds are burning on try, and i cant make any sense of the failures..

Could the errors be from another patch just before yours? I.e. you pushed on top of bustage?

> as for the comment, i suppose you prefer it directly within jscpucfg.h,
> explaining the previous status quo with __BYTE_ORDER and the direction posix
> goes ?

Yes please.

Comment 7

[Landry Breuil (:gaston)]

Lets retry..  https://tbpl.mozilla.org/?tree=Try&rev=f9df28d16fdc

Comment 8

[Landry Breuil (:gaston)]

All green this time, so yeah probably pushed on top of bustage..

as for the comment, would that do ?

/* historically, OSes providing <endian.h> only defined
 * __BYTE_ORDER to either __LITTLE_ENDIAN or __BIG_ENDIAN.
 * The austin group decided to standardise <endian.h> in
 * POSIX around 2011, expecting it to provide a BYTE_ORDER
 * #define set to either LITTLE_ENDIAN or BIG_ENDIAN. We
 * should try to cope with both possibilities here */

Comment 9

[Nicholas Nethercote [inactive]]

> All green this time, so yeah probably pushed on top of bustage..

Pushing to try from a mozilla-central generally avoids this problem. I have a script that copies patches from a mozilla-inbound repo to a mozilla-central repo and then pushes. Occasionally you get conflicts in the copying stage. Something to consider :)

That comment is perfect, word-wise. Just needs some tweaking of formatting and punctuation, viz:

/*
 * Historically, OSes providing <endian.h> only defined
 * __BYTE_ORDER to either __LITTLE_ENDIAN or __BIG_ENDIAN.
 * The Austin group decided to standardise <endian.h> in
 * POSIX around 2011, expecting it to provide a BYTE_ORDER
 * #define set to either LITTLE_ENDIAN or BIG_ENDIAN. We
 * should try to cope with both possibilities here.
 */

Once you've updated the patch, set the "checkin-needed" flag and you should be good. Thanks!

Comment 10

[Landry Breuil (:gaston)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/01223f8127da

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/01223f8127da