Lines Matching refs:order
2160 >0xc byte 00 \b, DOS 3.3 sector order
2163 >0xc byte 01 \b, ProDOS sector order
2254 # that I could find. The 1 and 2 really mean "order in which you defined
2266 # row- or column-order recalculation; the A or M means automatic or manual
2778 # coding indicated by setting the high-order bit of the leftmost byte
2842 # byte order as the machine running "file" with "cpio archive", and
2843 # to indicate archives produced on machines with the opposite byte order
2867 # They were written with binary values in host byte order, and
3140 # variant ASCII, 4K dictionary (strength=48=50-2). With strength=49 wrong order! WHY?
3143 # skip VAX-order 68k Blit mpx/mux executable (strength=50) handled by ./blit
3152 # variant ASCII, 2K dictionary (strength=48=50-2). With strength=49 wrong order! WHY?
3171 # variant ASCII, 1K dictionary (strength=48=50-2). With strength=49 wrong order! WHY?
3706 # standard suffix is ".j"; for multi volumes following order j01 j02 ... j99 100 ... 990
4789 # version; (0x0000) or (0x0001); for 0 all multi-byte are in host byte order. For 1 big endian
6898 # "VAX-order" and "VAX-order2"?
6902 0 short 03401 VAX-order 68K Blit (standalone) executable
6906 0 short 03001 VAX-order 68k Blit mpx/mux executable
6909 #>0 search/5536 main\0 VAX-order 68k Blit mpx/mux executable
8015 # XXX - what byte order does the Clipper use?
8545 # This magic number is byte-order-independent.
8550 # byte-order independent, and one of which is byte-order dependent?
10315 # Hash 1.85/1.86 databases store metadata in network byte order.
10316 # Btree 1.85/1.86 databases store the metadata in host byte order.
10317 # Hash and Btree 2.X and later databases store the metadata in host byte order.
10324 >>4 belong >0 (Hash, version %d, native byte-order)
10338 >>4 belong >0 (Hash, version %d, native byte-order)
10341 >4 long >0 (Btree, version %d, native byte-order)
10348 >16 long >0 (Hash, version %d, native byte-order)
10355 >16 long >0 (Btree, version %d, native byte-order)
10362 >16 long >0 (Queue, version %d, native byte-order)
10370 >16 long >0 (Log, version %d, native byte-order)
10859 >>502 uleshort x \b, sort order %u
11568 # We specify both byte orders in order to recognize byte-swapped dumps.
11802 # We have to check the byte order flag to see what byte order all the
12142 >5 byte 0 invalid byte order
12173 # XXX - needs to have the byte order specified (NS32K was little-endian,
14986 >36 lelong x \b, byte order %d
15683 # using native byte order.
15777 # All new-style FreeBSD magic numbers are in host byte order (i.e.,
15893 # 28: low order byte of the current PTD entry, always 0 since the
17592 # XXX - somebody should figure out whether any byte order needs to be
17603 # practice in order to avoid collisions.
17624 # The "misc" stuff needs a byte order; the archives look suspiciously
17634 0 long 01203604016 TML 0123 byte-order format
17635 0 long 01702407010 TML 1032 byte-order format
17636 0 long 01003405017 TML 2301 byte-order format
17637 0 long 01602007412 TML 3210 byte-order format
17881 # Unfortunately, HP-UX uses corehead blocks without specifying the order
17887 # The only observed order in real core files is KERNEL, EXEC, FORMAT, PROC
17888 # but we include all 6 variations of the order of the first 3, and
18721 # or uncompressed CFA RAW data. Byte order: Big Endian.
19755 # ByteOrder; byte order of image data: 0~least significant byte first 1~most significant byte first
19756 >>>>>28 ubelong >0 \b, order %u
19759 # BitmapBitOrder; bit-order of image data; apparently same as ByteOrder
19760 #>>>>>36 ubelong x \b, bit order %u
21179 # ulequad order: 0xGGGGGGGGRRRRRRRR, 0xAAAAAAAABBBBBBBB
23544 # "long" magic is a better practice in order to avoid collisions.
23779 # In order to aid telling these apart a new endian flag was added. In order
24373 # yes, this is separate from the low-order magic number bit
26410 # XXX - byte order?
26469 # The high-order word is an internal value that is implementation specific.
26470 # The low-order word is MINIDUMP_VERSION 0xA793
26500 # XXX - byte order?
27109 # byte order: 00h~little-endian non-zero=1~big-endian
27113 # word order: 00h~little-endian non-zero=1~big-endian
27114 #>0x03 ubyte =0 \b, little-endian word order
27115 #>0x03 ubyte !0 \b, big-endian word order
29199 >>0x400A string \0\0\0\0\0\0 MSX ROM with nonstandard page order
29207 >>0x800A string \0\0\0\0\0\0 MSX ROM with nonstandard page order
29215 >0x3C008 string \0\0\0\0\0\0\0\0 MSX MegaROM with nonstandard page order
29388 # All new-style magic numbers are in network byte order.
30648 # We have to check the byte order flag to see what byte order all the
30673 >5 byte 0 invalid byte order
30686 >>18 leshort 1 AT&T WE32100 - invalid byte order,
30687 >>18 leshort 2 SPARC - invalid byte order,
30689 >>18 leshort 4 Motorola 68000 - invalid byte order,
30690 >>18 leshort 5 Motorola 88000 - invalid byte order,
30693 >>18 leshort 8 MIPS R3000_BE - invalid byte order,
30694 >>18 leshort 9 Amdahl - invalid byte order,
30696 >>18 leshort 11 RS6000 - invalid byte order,
30697 >>18 leshort 15 PA-RISC - invalid byte order,
30719 >>18 beshort 3 Intel 80386 - invalid byte order,
30722 >>18 beshort 6 Intel 80486 - invalid byte order,
30726 >>18 beshort 10 MIPS R3000_LE - invalid byte order,
31351 # XXX - byte order?
31730 >4 byte >0 (net-order %d)
32415 # whose order conforms to a grammar:
32830 # XXX - byte order? Paging Hokey....
33149 # XXX - byte order?
33167 # two bytes of magic followed by "\r\n" in little endian order
34875 # XXX - byte order?
35849 # XXX - byte order?
37127 # ncurses6 (2015) uses this format, ignoring byte-order
