# a run b, b run c, c do SEGV, where is the BUG?



## kenorb (Nov 16, 2010)

This is general question, because I'm confused of POSIX standards.
Assuming that SEGV is a BUG., which must be fixed.

I run program A with empty param:

```
> ./a -
Segmentation fault (core dumped)
```
It could be obvious that bug is in software A, but:
software A using library B to check if the environment is right (so NULL from A is passed into B).
Then library B passing NULL into library C (/lib/libc.so.7) and it crashing on strlen().

At the end:
Company policy of software A says that it isn't a bug in their software, because I didn't read the manual. And I'm using with wrong option and this software is not designed to use with non-existing options. Just use it in normal way, it will work.
Company policy of library B says that it isn't a bug in their library, because they just passing the argument as it is. And when using standard system function length(), software A or library C should care about the NULLs.
Company policy of library C says that it isn't a bug in their library, because this function is not designed to run with NULL parameter, please fix the BUG in your software.

*Where is the BUG?*
And where it should be fixed then?


----------



## nORKy (Nov 16, 2010)

strlen(NULL) means "size of chain start at adresse 0x0". The number "0x0" is correct : the bug is not in strlen ; strlen does its job.
The adresse 0x0 is invalid in unix System (it is deliberate ; it is valid on Playstation) I think it's all callers (lib A and B) that must test if it's a valid adresse (lib b with != NULL) and a string terminated by a "\0" (lib A).


----------



## kenorb (Nov 16, 2010)

Real example from here:

```
#0  0x00000008092c05b7 in strlen () from /lib/libc.so.7
#1  0x0000000808dc9bc1 in std::char_traits<char>::length (__s=0x0) at char_traits.h:258
#2  0x0000000808dcbe15 in std::string::assign (this=0x7fffffffe4b0, __s=0x0) at basic_string.h:920
#3  0x0000000808dcbe45 in std::string::operator= (this=0x7fffffffe4b0, __s=0x0) at basic_string.h:499
#4  0x000000000070a87a in main (argc=1, argv=0x7fffffffe768) at main.cpp:113
```
Program executed without environment or proper options (#4, where this software is not designed to run without proper environment), then it passing the invalid parameters into libstdc++.so.6 (#3, #4), which passing invalid parameters into libc.so.7 (#1).
SEGV is in libc.so.7, software crashes.
libc.so.7 should check for NULL input, libstdc++.so.6, or the software?
Who should fix the BUG, or just any person who is happy to fix it in A, B or C?


----------



## nORKy (Nov 16, 2010)

kenorb said:
			
		

> where this software is not designed to run without proper environment



What do you mean ? You mean you do a volontary call error ?


For me, it's simplier.
The human must read A's manual, A must read B's manual, B must read C's manual...


----------



## nORKy (Nov 16, 2010)

About C++ usage :

```
string& operator= ( const string& str );
string& operator= ( const char* s );
string& operator= ( char c );

String assignment
Sets a copy of the argument as the new content for the string object.
The previous content is dropped.
The assign member function provides a similar functionality with additional options.

Parameters
str : string object. A copy of the content of this object is used as the new content for the object.
s: a pointer to an array containing a null-terminated character sequence (C string), which is copied as the new content for the object.
c: Character. The content is set to a single character.
```

So, the C++ compiler chooses this: string& operator= ( const char* s );
it's somthings like this : "String mystring = 0x0";
read the manual :

```
s: a pointer to an array containing a null-terminated character sequence (C string)
```
is 0x0 a null-terminated character sequence ?? NO (I'm sure, beacuse unix system don't use the adresse 0x0), so, the caller is the bug, not libC++ or libC


----------



## DutchDaemon (Nov 17, 2010)

This topic has been closed. Issues as technical or detailed as this should not be discussed in general user-oriented forums like The FreeBSD Forums. These forums are intended for end-user support with installing and/or running FreeBSD and/or applications from the ports tree, not for routinely resolving low-level problems with the operating system or add-on applications. Developers and port maintainers usually do not spend much time here, and we routinely refer technically detailed questions to them.

Consider opening this topic elsewhere, e.g.:

In the case of *the FreeBSD base system*:

1) by posting to one of the relevant mailing lists
2) by opening a bug report

In the case of *ported applications*:

1) by contacting the port maintainer (run make maintainer in the port directory)
2) by opening a bug report

Alternatively: there are plenty of general-purpose programming forums. Try there.


----------

