Page 9 of 10 FirstFirst ... 78910 LastLast
Results 81 to 90 of 99

Thread: How NOT to write a shared library

  1. #81
    Join Date
    Aug 2006
    Beans
    134

    Re: How NOT to write a shared library

    Quote Originally Posted by LaRoza View Post
    I have 2.5 GB of RAM. Explain this please....
    In addition to what Wybiral said, the reason the last line reports -2147483648 is that count is an unsigned int, so the true value of 2147483648 get rolled over to it's negative. The one after that (4GB) fails.

    Quote Originally Posted by Wybiral
    On my computer, "size_t" is limited to (2 ^ 32) - 1 or 4294967295.
    Interesting. In 32 bit windows memory pointers are unsigned so you are limited to 2^31 (2GB), though later versions let you compile with a flag to get about 3GB I think.

    You actually have to be careful with pointer arithmatic is it really is full 32 bit. Eg if you want to find pointer half way between *A & *B you might be tempted to do *C = (A+B)/2, this always works with 31 bit, but can fail in 32 bit if A + B > 2^32 (rolls over to a low number not half way between).

    DB

  2. #82
    Join Date
    Jan 2006
    Beans
    Hidden!
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Re: How NOT to write a shared library

    8GB of RAM, the following code makes my system freeze. (not checked completely).

    PHP Code:
    /*
     *      test.c
     *
     *      Copyright 2007 Vyacheslav Goltser <slavikg@gmail>
     *
     *      This program is free software: you can redistribute it and/or modify
     *      it under the terms of the GNU General Public License as published by
     *      the Free Software Foundation, either version 3 of the License, or
     *      (at your option) any later version.
     *
     *      This program is distributed in the hope that it will be useful,
     *      but WITHOUT ANY WARRANTY; without even the implied warranty of
     *      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     *      GNU General Public License for more details.
     *
     *      You should have received a copy of the GNU General Public License
     *      along with this program.  If not, see <http://www.gnu.org/licenses/>.
     */


    #include <stdio.h>
    #include <malloc.h>
    #include <unistd.h>
    #include <signal.h>

    #define SIZE 1024*1024*1024

    void handler(int n) {
        
    printf("I got a SIGINT\n");
        
    _exit(0);
    }

    int main(int argcchar** argv)
    {
        
    long long int i 1024*1024*1024;
        
    printf("Asking for %d eight times\n"SIZE);
        
    char *stuff1 = (char *)malloc(sizeof(char)*SIZE);
        
    char *stuff2 = (char *)malloc(sizeof(char)*SIZE);
        
    char *stuff3 = (char *)malloc(sizeof(char)*SIZE);
        
    char *stuff4 = (char *)malloc(sizeof(char)*SIZE);
        
    char *stuff5 = (char *)malloc(sizeof(char)*SIZE);
        
    char *stuff6 = (char *)malloc(sizeof(char)*SIZE);
        
    char *stuff7 = (char *)malloc(sizeof(char)*SIZE);
        
    char *stuff8 = (char *)malloc(sizeof(char)*SIZE);
        
    signal(SIGINT,handler);
        while (
    i--)    {
            *(
    stuff1+i)=0;
            *(
    stuff2+i)=0;
            *(
    stuff3+i)=0;
            *(
    stuff4+i)=0;
            *(
    stuff5+i)=0;
            *(
    stuff6+i)=0;
            *(
    stuff7+i)=0;
            *(
    stuff8+i)=0;
        }
        while (
    1sleep(1);
        return 
    0;

    I am infallible, you should know that by now.
    "My favorite language is call STAR. It's extremely concise. It has exactly one verb '*', which does exactly what I want at the moment." --Larry Wall
    (02:15:31 PM) ***TimToady and snake oil go way back...
    42 lines of Perl - SHI - Home Site

  3. #83
    Join Date
    Apr 2007
    Beans
    14,781

    Re: How NOT to write a shared library

    I also have a 64 bit processor, but I don't know if that makes a difference.

  4. #84
    Join Date
    Aug 2007
    Beans
    1

    Re: How NOT to write a shared library

    "The real kicker here is that you spent 10-20 minutes writing this post. "
    LOL
    How slow are you to write posts like this?

    I mean... give ME a break. 10-20 minutes for such a post?
    HAHAHAH you think anyone takes your guess for serious?

    "Did you even bother to spend time emailing the author of the library to express your concerns?"
    Why should he? There are two kinds of projects:
    One with documentation
    and one without.

    I dare claim Ogre3d became so popular because it emphasized on docu. And I tell you exactly what to do with code that comes without docu - throw it away so it will never be used.

    'Yeah, everyone should be "shot dead" because how they think something should be done.'
    I dont think everyone. Sometimes projects emerge that really improve things. People should have the liberty to do that. And I endorse everyone who does so, we need the good and better ideas. Every once in a while great projects emerge that replace crappy projects. This is very good and needed.

    But for sure those that are too f******* lazy to write documentation should be shot dead. No, not they... noone should be shot dead anyway. Bu the program they have written should be shot. Without mercy. Only then can a change happen.

    This is really a disease in the open source world - how can you excel with a better product if the product doesnt care about docu really? About teaching people? Why do so many old-style projects emphasize writing crappy man pages which are so boring - and once they done so, they stop it? This mindset must change. They should TEACH people how to use it, they should EXPLAIN reasons, and so on... and they should STOP with the archaic UNIX concept of throwing one man page out and telling everyone to RTFM.
    This attitude MUST DIE and people that pursue on this attitude MUST STOP.
    We are in the world of wikipedia and wikis, of trac management and myriads of other projects that help. But archaic coders dont bother.

    In fact, there are TONS of projects which need a lot of improvements altogether over older projects (not always...) but I wouldnt help a project that does not care about documentation at all.

    Keep your code to yourself in this case.
    Last edited by shevegen; November 18th, 2007 at 11:41 PM.

  5. #85
    Join Date
    Jun 2006
    Location
    CT, USA
    Beans
    5,267
    Distro
    Ubuntu 6.10 Edgy

    Re: How NOT to write a shared library

    I know projects where top developer creates code, with request to someone chime in and write basic docs. And someone does, and community of experts double-check it and make sure it is correct. This creates a way for top developers not to waste time on writing docs, and less expert people to contribute.

    And without shooting anyone

  6. #86
    Join Date
    Dec 2006
    Location
    Australia
    Beans
    1,097
    Distro
    Xubuntu 15.10 Wily Werewolf

    Re: How NOT to write a shared library

    Quote Originally Posted by LaRoza View Post
    I also have a 64 bit processor, but I don't know if that makes a difference.
    I don't think it does for this particular case. I also have a 64-bit processor, but Wybrial's code works just as he described it. I have 2 GB of RAM.

    Quote Originally Posted by pmasiar
    I know projects where top developer creates code, with request to someone chime in and write basic docs. And someone does, and community of experts double-check it and make sure it is correct. This creates a way for top developers not to waste time on writing docs, and less expert people to contribute.
    Documentation should be written parallel to the code itself. Or at least comment the code so that automatic documentation generators can extract the bare essentials from it.

    The HOWTO-style documentation can be written by the community, but the framework for that sort of thing should be established by the development team.

    The problem with a non-developer writing the documentation and relying on "experts" to check it, is that these "experts" are usually the developers. If the developers can't be arsed to write documentation to begin with, then the trend seems to be that they never bother check community documentation anyway. For non-developers to become "expert" with the software, they need time to learn the thing, and even then they don't have the depth of knowledge the developers do. At best, you end up with half-obsolete documentation or documentation with a lot of missing content.

    No. Developers should follow industry best-practice, which incidentally happens to be taught to IT students the world over: write documentation as you develop.

    Those projects you talk about must be exceptions to the general trend, not the usual case. Because there are a LOT of FOSS projects with ****-poor documentation (compare GTK's official docs with QT's docs from Trolltech, for example). I've tried to contribute myself to some of them, but for larger projects that is nigh impossible without copious leisure time.


    By the way, isn't this thread supposed to be about "How NOT to write a shared library"?
    Last edited by samjh; November 19th, 2007 at 12:45 AM.

  7. #87
    Join Date
    Jun 2006
    Location
    CT, USA
    Beans
    5,267
    Distro
    Ubuntu 6.10 Edgy

    Re: How NOT to write a shared library

    Quote Originally Posted by samjh View Post
    By the way, isn't this thread supposed to be about "How NOT to write a shared library"?
    Well, this thread was always a little rant about how FOSS sucks, so complaining about sucking docs is on topic

    To people complaining about sucky docs I have two comments:
    1) This is free software. If you understand **what** is wrong with docs, fix it, submit patch. Docs is text, exactly as sources. Would maintainers reject such a patch? And if they do, create another competitive doc website -- if it is so much better, it will be linked.
    2) Having bad docs (and sources) is still better than having no docs and no sources, just ask samba people.

    And if you say "this is less than perfect", I agree. I am not aware anybody promised anything being perfect in real life. What is?

  8. #88
    Join Date
    Dec 2006
    Location
    Australia
    Beans
    1,097
    Distro
    Xubuntu 15.10 Wily Werewolf

    Re: How NOT to write a shared library

    Quote Originally Posted by pmasiar View Post
    Well, this thread was always a little rant about how FOSS sucks, so complaining about sucking docs is on topic
    I disagree. The subliminal message in this thread is about improving the standards of FOSS projects, not a statement that they "suck".

    j_g doesn't click with PulseAudio developer's use of an exit() in a shared library, which is a valid criticism. Just because a lot of programmers do it because they can't be bothered to do robust error-handling doesn't mean that it's the right thing to do. Keeping with best-practice is usually inconvenient work; taking the easy route might be convenient, but if you want top-quality software, it is not the right way.

    While I don't agree with j_g's tone, the principle of his pointing out the ill-practice is not to be derided. He just managed to frame a valid criticism in a not-so-constructive way (shooting people? come on now).

  9. #89
    Join Date
    Jan 2006
    Beans
    Hidden!
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Re: How NOT to write a shared library

    the only libpurple documentation I've found was anotated function parameters ...

    everything else I deduced from looking at code flow (who calls what).
    I am infallible, you should know that by now.
    "My favorite language is call STAR. It's extremely concise. It has exactly one verb '*', which does exactly what I want at the moment." --Larry Wall
    (02:15:31 PM) ***TimToady and snake oil go way back...
    42 lines of Perl - SHI - Home Site

  10. #90
    Join Date
    Sep 2005
    Beans
    27

    Re: How NOT to write a shared library

    I'd like to point out that the g_malloc() function in GLib also exits. Where do we fill out the bug report to get glib and everything that uses it removed from Ubuntu, for stability reasons?

    Handling malloc() errors gracefully sounds good, but has little practical value. In a real-world situation where you were out of memory, malloc() will not actually return a 0. And if it did, there's not much you could do about it. If you're allocating 1GB at a time you have bigger problems than malloc checking..

    If your data is critical, there's another error case you should solve for that's much more common than OOM, which is LOP (Loss of Power). Solve the problem of how to make sure that your data is not lost when the power goes out, and you will find that you automatically have a solution to the OOM abort case as well.

Page 9 of 10 FirstFirst ... 78910 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •