strtok_r strange failure

[Emmanuel Dreyfus]

Hi

I have thins strange failure in strtok_r() on NetBSD-6.1.2/amd64

Breakpoint 1, load_descriptor (xmlnode=0x7f7ff7bdd680,
provider=0x7f7ff7b05400, role=LASSO_PROVIDER_ROLE_IDP) at
provider.c:356
356 LassoProviderPrivate *pdata = provider->private_data;
(gdb) n
358 int counter = 0;
(gdb)
361 value = getSaml2MdProp(xmlnode,
(gdb)
363 token = strtok_r((char*) value, " ", &saveptr);
(gdb) print value
$1 = (xmlChar *) 0x7f7ff7bc63e0 "urn:oasis:names:tc:SAML:2.0:protocol"
(gdb) n
364 while (token) {
(gdb) print token
$2 = 0xfffffffff7bc63e0 <Address 0xfffffffff7bc63e0 out of bounds>

token is almost correct: only the upper 32 bytes are wrong. Any idea of
what is going on?

[Rhialto]

Post by Emmanuel Dreyfus
(gdb) print token
$2 = 0xfffffffff7bc63e0 <Address 0xfffffffff7bc63e0 out of bounds>
token is almost correct: only the upper 32 bytes are wrong. Any idea of
what is going on?

First thought: header file not included, so strtok_r is not declared and
defaults to returning int.

-Olaf.

[Emmanuel Dreyfus]

Post by Rhialto
First thought: header file not included, so strtok_r is not declared and
defaults to returning int.

Worse than that: heander included, but missing _POSIX_C_SOURCE=199506
so that strtok_t() is not defined. Wow, this is tough.

Thank you for pointing it. I will add a patch in pkgsrc to fix that
software.

[Rhialto]

Post by Emmanuel Dreyfus
Worse than that: heander included, but missing _POSIX_C_SOURCE=199506
so that strtok_t() is not defined. Wow, this is tough.

I have seen effects like that when software starts defining things like
XOPEN_SOURCE or similar defines. Then suddenly other things like
_NETBSD_SOURCE no longer get defined, which may lead to various
functions or structures unexpectedly not being declared.

(Note: I've forgotten the exact details so the names I mention are
probably not the actual ones involved. But it happened in some software
project where somebody wanted to be "portable", except that the program
was using some non-POSIX but very common Unix features, and didn't
realise that the #define reduced features, instead of just making all
standard features available).

-Olaf.

[David Laight]

Post by Emmanuel Dreyfus

Post by Rhialto
First thought: header file not included, so strtok_r is not declared and
defaults to returning int.

Worse than that: heander included, but missing _POSIX_C_SOURCE=199506
so that strtok_t() is not defined. Wow, this is tough.

The compiler should have output a warning for the int -> pointer assignment.
For historic reasons that one isn't an error.

The 'no prototype' warning isn't enabled by default.

David

[Emmanuel Dreyfus]

Post by David Laight
The compiler should have output a warning for the int -> pointer assignment.
For historic reasons that one isn't an error.

On LP64 it would be much better if it was an error.

[David Holland]

Post by Emmanuel Dreyfus

Post by David Laight
The compiler should have output a warning for the int -> pointer
assignment. For historic reasons that one isn't an error.

On LP64 it would be much better if it was an error.

If your program doesn't build with -Wall -Werror you only have
yourself to blame...

[Emmanuel Dreyfus]

Post by David Holland

Post by Emmanuel Dreyfus
On LP64 it would be much better if it was an error.

If your program doesn't build with -Wall -Werror you only have
yourself to blame...

It is not my program, and unfortunately many projects do not do that. We
cannot expect the world to do The Right Thing.

[David Laight]

Post by Emmanuel Dreyfus

Post by David Holland

Post by Emmanuel Dreyfus
On LP64 it would be much better if it was an error.

If your program doesn't build with -Wall -Werror you only have
yourself to blame...

It is not my program, and unfortunately many projects do not do that. We
cannot expect the world to do The Right Thing.

There was be a "warning: assignment makes pointer from integer without a cast".
You shouldn't have ignored it.

David

[Emmanuel Dreyfus]

Post by David Laight

Post by Emmanuel Dreyfus
It is not my program, and unfortunately many projects do not do that. We
cannot expect the world to do The Right Thing.

There was be a "warning: assignment makes pointer from integer without a
cast". You shouldn't have ignored it.

Then it should be an error, not a warning.

[Mouse]

Post by Emmanuel Dreyfus

Post by David Laight
There was be a "warning: assignment makes pointer from integer
without a cast". You shouldn't have ignored it.

Then it should be an error, not a warning.

I'm not sure you're wrong - but I'm also not sure you're right; there
_are_ contexts where such a thing is reasonable and useful (memory
allocators and kernel internals come to mind), so at the very least it
needs to be disableable.

There's also historical precedent arguing for leaving it as a warning.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[David Sainty]

Post by Mouse

Post by Emmanuel Dreyfus

Post by David Laight
There was be a "warning: assignment makes pointer from integer
without a cast". You shouldn't have ignored it.

Then it should be an error, not a warning.

I'm not sure you're wrong - but I'm also not sure you're right; there
_are_ contexts where such a thing is reasonable and useful (memory
allocators and kernel internals come to mind), so at the very least it
needs to be disableable.

But surely in all those contexts you could reasonably demand an explicit
cast...

[David Holland]

Post by Emmanuel Dreyfus

Post by David Laight

Post by Emmanuel Dreyfus
It is not my program, and unfortunately many projects do not do that. We
cannot expect the world to do The Right Thing.

There was be a "warning: assignment makes pointer from integer without a
cast". You shouldn't have ignored it.

Then it should be an error, not a warning.

This is C, not Modula-3.

[Mouse]

Post by Emmanuel Dreyfus

Post by David Holland
If your program doesn't build with -Wall -Werror you only have
yourself to blame...

It is not my program, and unfortunately many projects do not do that.
We cannot expect the world to do The Right Thing.

FSVO "expect"[%]. But it certainly is not (y)our fault if they don't.

(I could also argue a little about the exact set of warnings; there are
a few -Wall warnings which I prefer to leave disabled.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[%] One definition of "expect" is "consider reasonable or due"; the
example usage I saw was "the school expects its students to arrive
on time". For that value of "expect", I think you can. But for
another definition - "consider probable or likely" - which I think
is probably the one you meant, I agree with you.

[Christos Zoulas]

Post by Emmanuel Dreyfus
Hi
I have thins strange failure in strtok_r() on NetBSD-6.1.2/amd64
Breakpoint 1, load_descriptor (xmlnode=0x7f7ff7bdd680,
provider=0x7f7ff7b05400, role=LASSO_PROVIDER_ROLE_IDP) at
provider.c:356
356 LassoProviderPrivate *pdata = provider->private_data;
(gdb) n
358 int counter = 0;
(gdb)
361 value = getSaml2MdProp(xmlnode,
(gdb)
363 token = strtok_r((char*) value, " ", &saveptr);
(gdb) print value
$1 = (xmlChar *) 0x7f7ff7bc63e0 "urn:oasis:names:tc:SAML:2.0:protocol"
(gdb) n
364 while (token) {
(gdb) print token
$2 = 0xfffffffff7bc63e0 <Address 0xfffffffff7bc63e0 out of bounds>
token is almost correct: only the upper 32 bytes are wrong. Any idea of
what is going on?

Prototype not in scope?

christos