Re: [releng_6 tinderbox] failure on sparc64/sparc64

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Warner Losh
In message: <[hidden email]>
            [hidden email] (Dag-Erling Smørgrav) writes:
: "M. Warner Losh" <[hidden email]> writes:
: > Ruslan Ermilov <[hidden email]> writes:
: > > I mean, I don't see a reason not to remove -fno-strict-aliasing
: > > from the kernel builds now.  Perhaps it's still needed for some
: > > platforms that aren't covered by tinderbox, not sure...  Can be
: > > easily checked with "make universe".
:
: First of all, the kernel Makefiles contain a hack which force
: -fno-strict-aliasing whether you want it or not.
:
: Second, the kernel will *not* build without -fno-strict-aliasing,
: partly because of preexisting aliasing violations and partly because
: of aliasing violations which were introduced after the hack (and could
: have been avoided if that hack had not been in place).
:
: > There's a dozen or two files that will fail to compile -O2 w/o it
: > spread through the tree.
:
: not throughout the tree - only in the kernel.

That's what I ment.

I've made some changes.  Some of which I'm pretty sure of, the other
I'm less sure of.  I've made the following changes:

imp         2006-02-04 22:51:03 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/an           if_an.c
  Log:
  Silence the strict-alias warnings.  Make a trip through (void *) when
  casting a structure to a uint32_t *.  Many drivers in the tree do this, but
  I'll not update them until these changes can be reviewed by the pedantic
  standards folks.
 
  Revision  Changes    Path
  1.78      +16 -16    src/sys/dev/an/if_an.c

http://cvsweb.FreeBSD.ORG/src/sys/dev/an/if_an.c


This driver wants to access these structures as arrays of uint32_t.
It used to cast directly, but that isn't allowed.  So, I've passed
the cast through a (void *).  Is that allowed?  Eg:

        struct foo foo;
        ((uint32_t *)(void *)&foo)[3] = 12;

is that OK?

Warner
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Stefan Farfeleder
On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
>
> This driver wants to access these structures as arrays of uint32_t.
> It used to cast directly, but that isn't allowed.  So, I've passed
> the cast through a (void *).  Is that allowed?  Eg:
>
> struct foo foo;
> ((uint32_t *)(void *)&foo)[3] = 12;
>
> is that OK?

I'm afraid that only silences the warning without solving the underlying
problem.  I don't think there's a Standard conforming way to treat a
struct foo as an uint32_t array.

Stefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Dag-Erling Smørgrav
Stefan Farfeleder <[hidden email]> writes:

> On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
> > This driver wants to access these structures as arrays of uint32_t.
> > It used to cast directly, but that isn't allowed.  So, I've passed
> > the cast through a (void *).  Is that allowed?  Eg:
> >
> > struct foo foo;
> > ((uint32_t *)(void *)&foo)[3] = 12;
> >
> > is that OK?
> I'm afraid that only silences the warning without solving the underlying
> problem.  I don't think there's a Standard conforming way to treat a
> struct foo as an uint32_t array.

A union should do the trick.

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Max Laier
In reply to this post by Stefan Farfeleder
On Sunday 05 February 2006 09:48, Stefan Farfeleder wrote:

> On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
> > This driver wants to access these structures as arrays of uint32_t.
> > It used to cast directly, but that isn't allowed.  So, I've passed
> > the cast through a (void *).  Is that allowed?  Eg:
> >
> > struct foo foo;
> > ((uint32_t *)(void *)&foo)[3] = 12;
> >
> > is that OK?
>
> I'm afraid that only silences the warning without solving the underlying
> problem.  I don't think there's a Standard conforming way to treat a
> struct foo as an uint32_t array.
You could embed the original struct contents with an uint32_t array in an
union.  That way you don't even have to cast.

e.g.:
struct foo {
        union {
                struct foo_orig {
                        field1;
                        field2;
                } orig;
                uint32_t array[SIZE];
        } wrap;
#define field1 wrap.orig.field1
#define field2 wrap.orig.field2
};

You should obviously make sure that the fields are named uniquely and the
header is private to you.

--
/"\  Best regards,                      | [hidden email]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Warner Losh
In reply to this post by Dag-Erling Smørgrav
In message: <[hidden email]>
            [hidden email] (Dag-Erling Smørgrav) writes:
: Stefan Farfeleder <[hidden email]> writes:
: > On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
: > > This driver wants to access these structures as arrays of uint32_t.
: > > It used to cast directly, but that isn't allowed.  So, I've passed
: > > the cast through a (void *).  Is that allowed?  Eg:
: > >
: > > struct foo foo;
: > > ((uint32_t *)(void *)&foo)[3] = 12;
: > >
: > > is that OK?
: > I'm afraid that only silences the warning without solving the underlying
: > problem.  I don't think there's a Standard conforming way to treat a
: > struct foo as an uint32_t array.
:
: A union should do the trick.

Does the answer change when all that's being done is reading the
contents of the memory to be sent out over, say, the pci bus to a
specific memory location?  The code I corrected in an does originally
was:

for (i = 0; i < sizeof(an_rx_desc) / 4; i++)
        CSR_MEM_AUX_WRITE_4(sc, AN_RX_DESC_OFFSET
                            + (desc * sizeof(an_rx_desc))
                            + (i * 4),
                            ((u_int32_t*)&an_rx_desc)[i]);

where the second arg is the offset in the card's memory and the third
arg is the 32-bit word to write.  an_rx_desc looks like:

struct an_card_rx_desc
{
        unsigned an_ctrl:15;
        unsigned an_done:1;
        unsigned an_len:15;
        unsigned an_valid:1;
        u_int64_t an_phys;
};

(note to self: this can't work on a big endian machine).

I can re-write these things with a union, but isn't there any other way?

Warner
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Erik Trulsson
In reply to this post by Dag-Erling Smørgrav
On Sun, Feb 05, 2006 at 04:45:34PM +0100, Dag-Erling Smørgrav wrote:

> Stefan Farfeleder <[hidden email]> writes:
> > On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
> > > This driver wants to access these structures as arrays of uint32_t.
> > > It used to cast directly, but that isn't allowed.  So, I've passed
> > > the cast through a (void *).  Is that allowed?  Eg:
> > >
> > > struct foo foo;
> > > ((uint32_t *)(void *)&foo)[3] = 12;
> > >
> > > is that OK?
> > I'm afraid that only silences the warning without solving the underlying
> > problem.  I don't think there's a Standard conforming way to treat a
> > struct foo as an uint32_t array.
>
> A union should do the trick.

No, it will not.  If you have a struct foo and try to access it as an array
of int, the program will have unspecified (and maybe even undefined)
behaviour.  It does not matter if you do it with a union or by casting
pointers.

In general, if you have an object of type X, then the only ways it can be
accessed is either as an object of type X, or as an array of [unsigned]
char.  


--
<Insert your favourite quote here.>
Erik Trulsson
[hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Warner Losh
In message: <[hidden email]>
            Erik Trulsson <[hidden email]> writes:
: On Sun, Feb 05, 2006 at 04:45:34PM +0100, Dag-Erling Smørgrav wrote:
: > Stefan Farfeleder <[hidden email]> writes:
: > > On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
: > > > This driver wants to access these structures as arrays of uint32_t.
: > > > It used to cast directly, but that isn't allowed.  So, I've passed
: > > > the cast through a (void *).  Is that allowed?  Eg:
: > > >
: > > > struct foo foo;
: > > > ((uint32_t *)(void *)&foo)[3] = 12;
: > > >
: > > > is that OK?
: > > I'm afraid that only silences the warning without solving the underlying
: > > problem.  I don't think there's a Standard conforming way to treat a
: > > struct foo as an uint32_t array.
: >
: > A union should do the trick.
:
: No, it will not.  If you have a struct foo and try to access it as an array
: of int, the program will have unspecified (and maybe even undefined)
: behaviour.  It does not matter if you do it with a union or by casting
: pointers.
:
: In general, if you have an object of type X, then the only ways it can be
: accessed is either as an object of type X, or as an array of [unsigned]
: char.  

So the proper fix for the above code is:

        struct foo foo;
        uint32_t value[sizeof(foo) / sizeof(uint32_t)];

        memcpy(value, &foo);
        // write out value one 32-bit word at a time

Is that right?  Or at least 'proper' here means defined.

Warner
       

       
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Giorgos Keramidas
On 2006-02-13 00:23, "M. Warner Losh" <[hidden email]> wrote:

> In message: <[hidden email]>
>             Erik Trulsson <[hidden email]> writes:
> : On Sun, Feb 05, 2006 at 04:45:34PM +0100, Dag-Erling Sm?rgrav wrote:
> : > Stefan Farfeleder <[hidden email]> writes:
> : > > On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
> : > > > This driver wants to access these structures as arrays of uint32_t.
> : > > > It used to cast directly, but that isn't allowed.  So, I've passed
> : > > > the cast through a (void *).  Is that allowed?  Eg:
> : > > >
> : > > > struct foo foo;
> : > > > ((uint32_t *)(void *)&foo)[3] = 12;
> : > > >
> : > > > is that OK?
> : > > I'm afraid that only silences the warning without solving the underlying
> : > > problem.  I don't think there's a Standard conforming way to treat a
> : > > struct foo as an uint32_t array.
> : >
> : > A union should do the trick.
> :
> : No, it will not.  If you have a struct foo and try to access it as an array
> : of int, the program will have unspecified (and maybe even undefined)
> : behaviour.  It does not matter if you do it with a union or by casting
> : pointers.
> :
> : In general, if you have an object of type X, then the only ways it can be
> : accessed is either as an object of type X, or as an array of [unsigned]
> : char.
>
> So the proper fix for the above code is:
>
> struct foo foo;
> uint32_t value[sizeof(foo) / sizeof(uint32_t)];
>
> memcpy(value, &foo);
> // write out value one 32-bit word at a time
>
> Is that right?  Or at least 'proper' here means defined.

AFAIK, yes.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Colin Percival-4
Giorgos Keramidas wrote:

> On 2006-02-13 00:23, "M. Warner Losh" <[hidden email]> wrote:
>> struct foo foo;
>> uint32_t value[sizeof(foo) / sizeof(uint32_t)];
>>
>> memcpy(value, &foo);
>> // write out value one 32-bit word at a time
>>
>> Is that right?  Or at least 'proper' here means defined.
>
> AFAIK, yes.

I agree that the behaviour of the above code is defined, but
I'd be much happier if value[] was defined to be an array of
length ((sizeof(foo) - 1) / sizeof(uint32_t) + 1), just in
case sizeof(foo) happens to not be a multiple of 4.  :-)

Colin Percival

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Giorgos Keramidas
On 2006-02-13 00:34, Colin Percival <[hidden email]> wrote:

>Giorgos Keramidas wrote:
>> On 2006-02-13 00:23, "M. Warner Losh" <[hidden email]> wrote:
>>> struct foo foo;
>>> uint32_t value[sizeof(foo) / sizeof(uint32_t)];
>>>
>>> memcpy(value, &foo);
>>> // write out value one 32-bit word at a time
>>>
>>> Is that right?  Or at least 'proper' here means defined.
>>
>> AFAIK, yes.
>
> I agree that the behaviour of the above code is defined, but
> I'd be much happier if value[] was defined to be an array of
> length ((sizeof(foo) - 1) / sizeof(uint32_t) + 1), just in
> case sizeof(foo) happens to not be a multiple of 4.  :-)

Good thinking.  It's probably a good idea to avoid copying random
garbage, and using something like:

    struct foo foo;
    uint32_t value[sizeof(uint32_t) * (sizeof(foo) / sizeof(uint32_t) + 1)];

and then copying only sizeof(foo) bytes.  This is probably defined too
and won't allow overflowing of value[], but I don't really want to know
what it does on machines of varying endianess :-)

- Giorgos

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Peter Jeremy
On Mon, 2006-Feb-13 10:48:02 +0200, Giorgos Keramidas wrote:
>Good thinking.  It's probably a good idea to avoid copying random
>garbage, and using something like:
>
>    struct foo foo;
>    uint32_t value[sizeof(uint32_t) * (sizeof(foo) / sizeof(uint32_t) + 1)];

That makes it about 4 times too large - you don't need to multiply by
sizeof(uint32_t).

>and then copying only sizeof(foo) bytes.

And zeroing any remaining bytes to prevent uninitialised data leaking out
of the kernel.

>and won't allow overflowing of value[], but I don't really want to know
>what it does on machines of varying endianess :-)

No worse than trying to write (uint32_t *)&foo;

BTW, the compiler is free to insert padding bytes into struct foo so
it would need to be explicitly zeroed and then the required fields
individually copied in.

--
Peter Jeremy
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Giorgos Keramidas
On 2006-02-13 20:38, Peter Jeremy <[hidden email]> wrote:
> On Mon, 2006-Feb-13 10:48:02 +0200, Giorgos Keramidas wrote:
> >Good thinking.  It's probably a good idea to avoid copying random
> >garbage, and using something like:
> >
> >    struct foo foo;
> >    uint32_t value[sizeof(uint32_t) * (sizeof(foo) / sizeof(uint32_t) + 1)];
>
> That makes it about 4 times too large - you don't need to multiply by
> sizeof(uint32_t).

Ugh!  Yes, you're right of course :)


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Warner Losh
In reply to this post by Colin Percival-4
In message: <[hidden email]>
            Colin Percival <[hidden email]> writes:
: Giorgos Keramidas wrote:
: > On 2006-02-13 00:23, "M. Warner Losh" <[hidden email]> wrote:
: >> struct foo foo;
: >> uint32_t value[sizeof(foo) / sizeof(uint32_t)];
: >>
: >> memcpy(value, &foo);
: >> // write out value one 32-bit word at a time
: >>
: >> Is that right?  Or at least 'proper' here means defined.
: >
: > AFAIK, yes.
:
: I agree that the behaviour of the above code is defined, but
: I'd be much happier if value[] was defined to be an array of
: length ((sizeof(foo) - 1) / sizeof(uint32_t) + 1), just in
: case sizeof(foo) happens to not be a multiple of 4.  :-)

It won't matter given how I'm going to fix this problem...

Warner
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Bruce Evans
[Someone wrote that certain accesses except via unsigned char are undefined.]

On Mon, 13 Feb 2006, M. Warner Losh wrote:

> In message: <[hidden email]>
>            Colin Percival <[hidden email]> writes:
> : Giorgos Keramidas wrote:
> : > On 2006-02-13 00:23, "M. Warner Losh" <[hidden email]> wrote:
> : >> struct foo foo;
> : >> uint32_t value[sizeof(foo) / sizeof(uint32_t)];
> : >>
> : >> memcpy(value, &foo);
> : >> // write out value one 32-bit word at a time
> : >>
> : >> Is that right?  Or at least 'proper' here means defined.
> : >
> : > AFAIK, yes.
> :
> : I agree that the behaviour of the above code is defined, but
> : I'd be much happier if value[] was defined to be an array of
> : length ((sizeof(foo) - 1) / sizeof(uint32_t) + 1), just in
> : case sizeof(foo) happens to not be a multiple of 4.  :-)

The behaviour of the above code is highly undefined.  There is no
`size' arg in the call to memcpy(), and fixing this alone leaves various
bugs and a complicated analysis to show that the behaviour is not
completely undefined.  The C standard only explicitly defines copying
from an object _to_ an array of unsigned char.  That copying back
doesn't give undefined behaviour is only implicitly defined.  The
above is much further from being explictly defined since it copies
essentially random bits _from_ a nameless intermediate array of unsigned
char to another object.  The behaviour would certainly be undefined for
most types of final object since there may be trap bits in the final
object, or it might just be implementation defined and not what is wanted
because there are non-trap padding bits in the final object.  However,
uint32_t doesn't have any padding bits, so it may be possible to show
that the behaviour of accessing the final object is defined (and useful).
I think this is equivalent to showing that the behaviour of the following
is defined:

  auto uint32_t value;

  value = 0; /* undefined without this? */
  memset(&value, random(), 1);
  value++;

> It won't matter given how I'm going to fix this problem...

Why not just access the object as an array of unsigned chars as someone
wrote?  Write it out 1 unsigned char at a time for the simple version.
This avoids the complications.

Bruce
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Warner Losh
In message: <[hidden email]>
            Bruce Evans <[hidden email]> writes:
: > It won't matter given how I'm going to fix this problem...
:
: Why not just access the object as an array of unsigned chars as someone
: wrote?  Write it out 1 unsigned char at a time for the simple version.
: This avoids the complications.

Because it has to be fed to the hardware 4 bytes at a time.

Warner
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [releng_6 tinderbox] failure on sparc64/sparc64

Giorgos Keramidas
On 2006-02-13 21:05, "M. Warner Losh" <[hidden email]> wrote:
> In message: <[hidden email]>
>             Bruce Evans <[hidden email]> writes:
> : > It won't matter given how I'm going to fix this problem...
> :
> : Why not just access the object as an array of unsigned chars as someone
> : wrote?  Write it out 1 unsigned char at a time for the simple version.
> : This avoids the complications.
>
> Because it has to be fed to the hardware 4 bytes at a time.

That's still possible, using an intermediate unsigned char buffer, or if
that's too much to ask (i.e. because keeping a duplicate copy of the
'foo' structure is a waste of memory), using a 4-byte scratch buffer and
iterating over an (unsigned char *) pointer through `foo'.

I think, that given a `foo' struct defined as:

    struct foo {
        uint32_t a;
        uint16_t b;
        uint16_t c;
        uint8_t  d;
        uint8_t  e;
    };

You are always allowed to use an (unsigned char *) pointer to iterate
through its bytes, as in:

    #include <stdint.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    struct foo {
        uint32_t        a;
        uint16_t        b;
        uint16_t        c;
        uint8_t         d;
        uint8_t         e;
    };

    int
    main(void)
    {
        struct foo foo;
        size_t k;

        memset(&foo, 0, sizeof(foo));
        foo.a = 1;
        foo.b = 2;
        foo.c = 3;
        foo.d = 4;
        foo.e = 5;

        for (k = 0; k < sizeof(foo); k++)
            printf("%s%02x", k ? " " : "", *((unsigned char *)&foo + k));
        putchar('\n');
        return EXIT_SUCCESS;
    }

This prints padding bytes correctly here, even with:

    $ CFLAGS='-std=c99 -pedantic' make WARNS=6 foo.c
    [...]
    $ ./foo
    01 00 00 00 02 00 03 00 04 05 00 00
    $

Then, if there's a 4-byte constraint, a single uint32_t can be used as a
'buffer':

    #include <stdint.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    struct foo {
        uint32_t        a;
        uint16_t        b;
        uint16_t        c;
        uint8_t         d;
        uint8_t         e;
    };

    int
    main(void)
    {
        struct foo foo;
        size_t k, nbytes;
        uint32_t x;

        memset(&foo, 0, sizeof(foo));
        foo.a = 1;
        foo.b = 2;
        foo.c = 3;
        foo.d = 4;
        foo.e = 5;

        for (k = 0; k < sizeof(foo); k++)
            printf("%s%02x", k ? " " : "", *((unsigned char *)&foo + k));
        putchar('\n');

        for (k = 0; k < sizeof(foo); k += 4) {
            nbytes = sizeof(uint32_t);
            if (sizeof(foo) - k < nbytes) {
                nbytes = sizeof(foo) - k;
                memset(&x, 0, sizeof(x));
            }
            memcpy(&x, ((unsigned char *)&foo + k), nbytes);
            printf("%s%zdb/%08x", k ? " " : "", nbytes, x);
        }
        putchar('\n');
        return EXIT_SUCCESS;
    }

and it seems to work as expected here on a little-endian machine:

    $ ./foo
    01 00 00 00 02 00 03 00 04 05 00 00
    4b/00000001 4b/00030002 4b/00000504

This probably works much better than trying to cast the original into an
array of uint32_t objects too :)

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"