Segmentation Fault

[Mike Wahler]

Hi all,

can anybody help me with the following code:

#include <stdio.h>
#include <emmintrin.h>
#define M 2
int main () {
int i;
__m128d *s, ts, td;

The header <emmintrin.h> and that type '__m128d'
are not part of standard C, and I don't know what
they are, but here are a few points:

double *p = malloc(M*sizeof(*p)); //A

You didn't #include <stdlib.h> for the prototype of
'malloc()', so a (C89) compiler will assume it returns
type 'int'. So the return value is type 'int' before
you assign it to the pointer 'p'. Very possible the
value has been corrupted.

// double p[2]; //B

This form will guarantee that the expression 'p' does
indeed evaluate to type 'double *' with a valid address
value. This (given that I've actually identified the
problem above) would be why this way works and above does
not.

if (p==NULL) return 0;

You might want to output some kind of message before
returning to give some visual clue of a problem.

p[0]=p[1]=1.0;

printf("%.3f %.3f\n", p[0], p[1]);

s = (__m128d *)p; //D

The language gives no guarantee that such a cast
will give a meaningful result. I must leave it
up to you to make sure it does (check your documentation).

if (s != p) return 0;

Same thing here: the language doesn't guarantee a
meaningful result for this comparison.

ts = *s;

This is perfectly valid as long as what's stored at
address 's' has a valid type '__m128d' value.

td = _mm_add_pd(ts, ts);

I can't comment on the nonstandard '_mm_add_pd()' function.
You might want to double check your documentation to ensure
you're using it correctly.

*s = td; //C

This is OK as long as 'td' contains a valid type '__m128d' value.

printf("%.3f %.3f\n", p[0], p[1]);
}

Line "C" causes a Segmentation Fault and I don't know why. If I replace line
"A" with line "B" it works correctly. Something must be wrong with line

"D"

Possibly. But I can't know since what you're doing is not standard C.
It could easily be valid for your implemenation. Double check your
documentation.

maybe somebody knows what?

My best guess is what I stated above: lacking a prototype, your
compiler is converting the address returned from 'malloc()' to
type 'int', thus corrupting it.

-Mike

 

[Arthur J. O'Dwyer]

There are plenty of good uses of casts and there are also cases where
the language definition imposes the usage of dubious casts

I cannot think of any uses for casting *imposed* by the language
definition. There is the usual exception-to-the-general-rule

foo *p = ...;
printf("%p", (void*)p);

but that's just a shorter version of the castless

foo *p = ...;
void *vp = p;
printf("%p", vp);

(try to implement strchr if you need an example).

The language definition specifically *prohibits* the programmer
from implementing 'strchr'. And a good thing too, because if the
'strchr' function weren't provided by the standard library, it
would be impossible to write in standard C without resorting to
casting away 'const'! (So in this case, the language definition
*saves* the programmer from having to perform any dubious casts.)

In other words, bad example. And I don't recall any *good*
examples offhand, either. Perhaps something involving a maze
of function pointers...

-Arthur

 

[Irrwahn Grausewitz]

I cannot think of any uses for casting *imposed* by the language
definition.

See end of post.

There is the usual exception-to-the-general-rule

foo *p = ...;
printf("%p", (void*)p);

but that's just a shorter version of the castless

foo *p = ...;
void *vp = p;
printf("%p", vp);

But you're not going to advocate the use of the latter to avoid the
cast in the former, are you?

And I don't recall any *good*
examples offhand, either.

Passing arguments of type char to any of the character classifications
functions from ctype.h without prior casting to unsigned character
might invoke undefined behaviour on implementations where 'plain' char
is signed.

<snip>

Regards

 

[Arthur J. O'Dwyer]

I cannot think of any uses for casting *imposed* by the language
definition.
void *vp = p;
printf("%p", vp);

But you're not going to advocate the use of the latter to avoid the
cast in the former [snipped], are you?

No, I don't advocate the latter; but I point out that the former's
cast is not strictly necessary.

Passing arguments of type char to any of the character classifications
functions from ctype.h without prior casting to unsigned character
might invoke undefined behaviour on implementations where 'plain' char
is signed.

This can also always be done with an implicit conversion, unless I'm
mistaken. The conversion from 'char' to 'unsigned char' is always
well-defined; thus

... isfoo((unsigned char)ch) ...

is always equivalent to the castless

unsigned char uch = ch;
... isfoo(uch) ...

Again, not necessarily advocated, but certainly possible.

-Arthur

 

[Irrwahn Grausewitz]

This can also always be done with an implicit conversion, unless I'm
mistaken. The conversion from 'char' to 'unsigned char' is always
well-defined; thus

... isfoo((unsigned char)ch) ...

is always equivalent to the castless

unsigned char uch = ch;
... isfoo(uch) ...

Again, not necessarily advocated, but certainly possible.

Agreed. So, while in most (if not all [*]) cases a cast can be
circumvented at some cost, it's still a useful concept, if only
to avoid that additional cost.

[*] Modulo Dan comes up with one or more of the "cases where the
language definition imposes the usage of dubious casts".

Regards

 

[CBFalconer]

.... snip ...

In other words, bad example. And I don't recall any *good*
examples offhand, either. Perhaps something involving a maze
of function pointers...

of twisty function pointers, all alike (and thus compatible).

 

[Jeremy Yallop]

I cannot think of any uses for casting *imposed* by the language
definition.

Converting between a pointer to void and intptr_t needs a cast. In
general, converting between types that are not assignment-compatible
and do not have the same representations requires a cast. There
aren't many such cases where such conversions are semantically valid,
though.

The language definition specifically *prohibits* the programmer
from implementing 'strchr'. And a good thing too, because if the
'strchr' function weren't provided by the standard library, it
would be impossible to write in standard C without resorting to
casting away 'const'!

You can implement a strchr-like function without using a cast:

char *castless_strchr(const char *string0, int c)
{
char *string;
memcpy(&string, &string0, sizeof string);
/* ... */
}

Jeremy.

 

[Dan Pop]

I cannot think of any uses for casting *imposed* by the language
definition.

This is entirely due to the limitations of your brain.

There is the usual exception-to-the-general-rule

foo *p = ...;
printf("%p", (void*)p);

but that's just a shorter version of the castless

foo *p = ...;
void *vp = p;
printf("%p", vp);

Are you advocating it as a worthy alternative?

The language definition specifically *prohibits* the programmer
from implementing 'strchr'.

Not if I am the implementor of the C library and I am working in a
freestanding environment. I.e. I've finished writing my compiler and I'm
writing now its standard C library.

'strchr' function weren't provided by the standard library, it
would be impossible to write in standard C without resorting to
casting away 'const'! (So in this case, the language definition
*saves* the programmer from having to perform any dubious casts.)

In other words, bad example.

Don't be idiot! ANY strchr-like function has exactly the same problems
as strchr. Imagine a function searching for groups of three characters
in ascending order inside a string...

And I don't recall any *good*
examples offhand, either. Perhaps something involving a maze
of function pointers...

Try converting a pointer to const something into a pointer to something
without using a cast. The strchr example was supposed to be a HUGE clue,
but you still managed to miss it...

Dan

 

[CBFalconer]

.... snip ...

You can implement a strchr-like function without using a cast:

char *castless_strchr(const char *string0, int c)
{
char *string;
memcpy(&string, &string0, sizeof string);
/* ... */
}

Remind us not to hire you, oh up-blower of systems.

 

[Alberto =?iso-8859-1?Q?Gim=E9nez?=]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 23 Jun 2004 18:46:27 GMT, Jeremy Yallop escribió:

char *castless_strchr(const char *string0, int c)
{
char *string;

^^^^--> not initialized

memcpy(&string, &string0, sizeof string); ^^^--> seg fault?
/* ... */
}

- --
Luis Alberto Giménez
GnuPG ID: 0x3BAABDE1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFA2jGU0keCtzuqveERAvjfAJwLGWMd+fhp/NigS+xlLINPYLqBWQCgld4p
qeIJWmbRINg5sRlVwehWleY=
=fijh
-----END PGP SIGNATURE-----

 

[Ulrich Eckhardt]

If the *only* way of *correctly* writing a piece of code requires a cast,
how can you claim that they are always wrong?

There are plenty of good uses of casts and there are also cases where
the language definition imposes the usage of dubious casts

You are right, that does not convey the full meaning.
Let me rephrase that a bit: if you cast, you should be able to justify that
cast well. If you just need the cast so the compiler swallows some code,
the code is wrong.

(try to implement strchr if you need an example).

IMHO strchr() is broken, since it easily lets you violate const
correctness. Therefore, the only thing that comes to my mind is to fix the
interface(yes, that's pretty hard for such an old interface, but I would
not easily accept new, similar code):
char const* strcchr( char const*, int);
char* strchr( char*, int);

Uli

 

[Dan Pop]

You are right, that does not convey the full meaning.
Let me rephrase that a bit: if you cast, you should be able to justify that
cast well. If you just need the cast so the compiler swallows some code,
the code is wrong.

I entirely agree with this version.

Dan

 

[Dan Pop]

El 23 Jun 2004 18:46:27 GMT, Jeremy Yallop escribió:

^^^^--> not initialized

Indeed. That's what the following memcpy call is for.

^^^--> seg fault?

Nope. If you can't tell the difference between "string" and "&string"
you have to either get new glasses or learn C.

Dan

 

[Alberto =?iso-8859-1?Q?Gim=E9nez?=]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 24 Jun 2004 16:56:38 GMT, Dan Pop escribió:

Nope. If you can't tell the difference between "string" and "&string"
you have to either get new glasses or learn C.

Sorry, my mistake (i actually have to get a new brain and stop java
programming). But can't see the point of not just assign string0 to
string (they're not the same type?).

- --
Luis Alberto Giménez
GnuPG ID: 0x3BAABDE1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFA2xJE0keCtzuqveERAkxbAJkBEhcEq2gWOElhr2gTNFnx9mGcEACeNrnD
FoCoPDIy/NxEgohJ2Q90mpM=
=IcvW
-----END PGP SIGNATURE-----

 

[Arthur J. O'Dwyer]

El 24 Jun 2004 16:56:38 GMT, Dan Pop escribió:

Sorry, my mistake (i actually have to get a new brain and stop java
programming). But can't see the point of not just assign string0 to
string (they're not the same type?).

That's correct; they're not the same type. The following two lines,
which you snipped from your reply, answer the other half of your question.

You can implement a strchr-like function without using a cast:
^^^^^^^^^^^^^^^^^^^^
char *castless_strchr(const char *string0, int c)

^^^^^^^^^^^^^^^

-Arthur

 

[Dan Pop]

El 24 Jun 2004 16:56:38 GMT, Dan Pop escribió:


Sorry, my mistake (i actually have to get a new brain and stop java
programming). But can't see the point of not just assign string0 to
string (they're not the same type?).

Nope, they don't have assignment compatible types. The direct
assignment would require a conversion from pointer to const char
to pointer to char and the purpose of the exercise was to avoid
the cast. Since both pointer types are guaranteed to have the
same representation, the assignment can be avoided by copying the
representation of one into another.

Of course, this is only a theoretical point, nobody recommends it as a
practical alternative to a normal assignment and a cast.

Dan

 

[Dave Thompson]

Don't be idiot! ANY strchr-like function has exactly the same problems
as strchr. Imagine a function searching for groups of three characters
in ascending order inside a string...

Only for a strict reading of 'strchr-like'. For your own function you
don't have the backward-compatibility requirement standard routines
did; you can choose to provide only the const interface, or only the
nonconst, or both separately which you can implement without cast and
without _writing_ duplicate code by putting (most of) the body in an
#include'd file or macro body. Okay, yuck, but it's _possible_.

More realistically you can, and in some cases I prefer to, return an
offset/index rather than a pointer; such an offset can be added or
subscripted to either/any qualification of pointer and is also good
(better) for simultaneously reducing a count_left, adding to
statistics, and the like.


- David.Thompson1 at worldnet.att.net

 

[Dan Pop]

Only for a strict reading of 'strchr-like'. For your own function you
don't have the backward-compatibility requirement standard routines
did;

Are you sure strchr itself was not a committee invention and, therefore,
was free of *any* backward-compatibility issues? The pre-ANSI function
for this purpose was index.

Dan

 

[lawrence.jones]

Are you sure strchr itself was not a committee invention and, therefore,
was free of *any* backward-compatibility issues? The pre-ANSI function
for this purpose was index.

No, the pre-ANSI BSD Unix function was index, the pre-ANSI AT&T Unix
function was strchr. I have no idea which came first, but both predated
ANSI C by a long time.

-Larry Jones

Nothing spoils fun like finding out it builds character. -- Calvin