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

Status
Not open for further replies.
kenorb

kenorb

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:
Code: 
> ./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?
 
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).
 
Real example from here:
Code: 
#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?
 
kenorb said:
where this software is not designed to run without proper environment
Click to expand...

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...
 
About C++ usage :
Code: 
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 :
Code: 
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
 
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.
 
Status
Not open for further replies.
Back
Top