Announcement

Collapse
No announcement yet.

Richard Stallman Announces GNU C Language Reference Manual

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by coder View Post
    If you think it's better to have dangling locks and leak file descriptors (which also means likely unflushed data, as you mentioned) than to safeguard their release via garbage collection, then you're operating under a very different world view than I am. I didn't say there's no benefit to having explicit unlocks or file closures -- just that I'd want garbage collection as a backstop.
    Perhaps I am viewing things differently. But, no, I do not want a "backstop" or "safeguard" in my code for this kind of thing. I want safeguards at the OS level - an OS (here I mean general purpose OS's running unknown programs, rather than RTOS'es or other specialised systems) should assume that programs are full of bugs and leak. It must clear up all resources a program might have taken, once the program ends, dies, or is forcibly killed.

    I want the programmer to use the correct language constructs for the task in hand. Then you do not need backstops - they add nothing but confusion and totally untestable code. You cannot rely on garbage collection handling the release of critical resources at an appropriate time. Therefore, you must use something else - something that you can rely on. And once you have that, garbage collection is no longer relevant.

    You're failing to distinguish between what the language actually implements vs. the prescribed best practices. If we take the example of a Python with statement, that simply builds atop the object's existing semantics. It closes the file or releases the lock because that's what the object's destructor does. So, you're wrong to say that Python doesn't use garbage collection for those things, but what it does is provide a better alternative mechanism.
    Locks (and file handles, and other non-memory resources) are not handled by destructors in correctly written Python. They are handled by "with" statements - the release is deterministic (to the extent that Python is deterministic) and synchronous, as the "__exit__" method is called at the end of the "with" statement. Before "with" statements were introduced to Python, try/finally blocks were used.

    It is possible that you are mixing up deterministic destructors and the term "garbage collection". That would explain a lot of our disagreement here.

    Garbage collection is asynchronous and non-deterministic, and used to clear up memory from old objects once there are no longer any live references to them. There are various garbage collection algorithms (with different advantages and disadvantages), but they typically involve running through the working memory looking for object references. By working in the background (often in their own thread), they save the main working thread(s) a little effort. But they don't always catch everything, and may need to lock memory areas.

    Destructors in a language like C++ run at precisely specified points in the code - they run when the object's lifetime ends. For local objects, that matches the end of their scope. It is absolutely fine to use such synchronous destructors for releasing resources - it is the preferred method, since it is automatic and you are guaranteed that the destructor will run regardless of exceptions. Python does not have such synchronous cleanup for its normal "__del__" destructor methods. But it does have them in the "__exit__" methods of objects that can be used in "with" statements. Thus in Python, you use "with" statements for resources, and do not rely on garbage collection. In C++, where destructors are synchronous, you use RAII ("Resource Acquisition Is Initialisation") for all resources, including memory. (There are techniques available if you want asynchronous resource release.)

    ​The question you need to ask is: what if you didn't catch it? For an arbitrary mutex, would it be better to have a dangling-lock bug that you might not even hit in testing, before the software is in the hands of customers? Or would you rather the lock get freed eventually? I know some people prefer the more catastrophic failure, but that presumes very good test coverage, which often isn't the case.
    Would I rather have one bad and unpredictable bug happen, or a different bad and unpredictable bug? Really, it's a silly question. Obviously I don't want either - and equally obviously, I know that no development process and no programmer is infallible, and there is always a non-zero risk of bugs slipping through in a final product. But I also know that extra code that should never be run, and is totally untestable, is always a liability. If your code correctly frees your locks (or other resources) at the right time, you will never see this garbage collection fallback. You will never know what other effects it has, what bugs it has, how it interacts with other parts of the code. And if your code does not correctly free the locks, what makes you think that freeing them by garbage collection will help? By the time that happens, all sorts of other things could have failed as a result of the lock being unavailable.

    No, the way to handle locks and critical resources is to have clearly defined methods of handling them. If you are programming in Python, you know all lock acquisition must take place within a "with" statement. If you are using Java, use a "try/finally" block. For C++, use RAII. Use the standard, clear and safe methods available for the language in question. Write the code in a clear manner - such as keeping the containing block small so that it is obvious it is correct.

    While debugging, you might make use of hooks in your garbage collection that check for lost locks - but they should not release the lock. They should yell at the developer, with any information they can give to help find the bug.

    ​What about file descriptors, where the program leaks more and more fds, the longer it runs, until operations utilizing file descriptors just randomly start failing? Is that a preferable outcome?

    I think you're being too idealistic.
    I am perhaps idealistic, but I don't think I am too idealistic. I want to write code using sensible techniques that are known to avoid certain classes of errors. I want other people to do that too. I want programs to be written in a responsible manner. Is that really too much to ask?

    Comment


    • #92
      Originally posted by Developer12 View Post

      Side note: Have people read up on the colossal fuckup with wikipedia? It used to be under the same licence as this reference book.....until the FSF wrote a *very* specific backdoor escape into a new version of the licence, with the express purpose of allowing the relicence of the whole of wikipedia as creative commons. Effectively conversion from GPL to BSD. Without the consent or consultation of any of the many prexisting contributors. see: https://twitter.com/marcan42/status/1376418013151338496

      The FSF can and will use the "or any later version" clause to unilaterally relicence your work without your consent, should it suit their purposes. Do not include it. This is to say *nothing* of the absolute absurdity of transferring the copyright of your work to them, which they demand for many GNU projects.

      The bottom line: Don't trust the FSF to do what's right, don't trust Stallman to do what's right. They are not incorruptible and concentrating all power over free software in one place was a Bad Fucking Idea from the start.
      The GFDL is a garbage license to begin with, there's a reason why I didn't include it in my enumeration. So that change was probably for the better, it's a pity that they made the CC-BY-SA option such a specific workaround instead of a general possibility.

      Comment


      • #93
        Originally posted by archkde View Post

        The GFDL is a garbage license to begin with, there's a reason why I didn't include it in my enumeration. So that change was probably for the better, it's a pity that they made the CC-BY-SA option such a specific workaround instead of a general possibility.
        It's exactly by design that they made it so narrow, and they would have made it far more narrow if they could have. In fact I think they would have preferred to name wikipedia itself specifically if they could have gotten away with it.

        They will *never* make this sort of thing generally available. This entire act was blatant hypocrisy, unilaterally releasing an organization which was using one of their (still) touted licences from the legal obligations they had to their users.

        For the FSF and their usual stances, this was philosophically equivalent to producing an updated GPLv4 with a clause allowing projects called "Linux" to be relicenced under the non-copyleft MIT. It's not hard to imagine that would spark considerable outrage, given virtually everyone who has ever contributed to linux has done so with the expectation that their work would remain governed by copyleft requirements forever. This is why Linus has explicitly stated that Linux does not carry the "or any later" clause, locking the FSF out of future meddling with Linux's copyright licencing.

        Comment


        • #94
          Originally posted by coder View Post
          Though it's a very good book, I wouldn't recommend the 2nd edition (which I used) to anyone learning C, today.
          I'm curious to know why? Can you explain more please? Thank you!

          Comment


          • #95
            Originally posted by reza View Post
            I'm curious to know why? Can you explain more please? Thank you!
            Because C11 is different enough than C89. Many of those new language features not only deserve an introduction, but they also affect programming style, which is something else a good language manual tries to begin establishing. Some of these features also mean that you can shift attention away from aspects of the original standard, such as the way C99's inline functions drastically reduce the need for macros.

            Some other notable additions in C99 and C11:
            • Intermingled declarations & code
            • // comments
            • stdbool.h
            • stdatomic.h
            • threads.h
            • compound literals
            • designated initializers
            • static assertions
            • _Generic keyword
            • unicode support
            • variadic macros

            Not that you'd necessarily cover all of these things, but at least you can dance around some of them in a way that acknowledges their existence.

            Comment


            • #96
              Originally posted by DavidBrown View Post

              Ask for your money back from the university - if they taught you C in your first year, it was a C coding class, not a computer science degree.
              I'm well aware of how trash my university was. I had 0 job prospects at graduation so felt forced to go to grad school, no internships or part time jobs to show. I finished undergrad 6 years ago and the best job I've landed is a Data Center Technician role. Before that I was a help desk tech, and before that I was a Graduate Teaching Assistant. I had a moderately high ACT score and went to the closest school to home to maximize my money and I wound up getting a full ride through undergrad, BUT trash is trash even if for free.

              Comment


              • #97
                Originally posted by kylew77 View Post
                I'm well aware of how trash my university was. I had 0 job prospects at graduation so felt forced to go to grad school, no internships or part time jobs to show. I finished undergrad 6 years ago and the best job I've landed is a Data Center Technician role.
                Did your job search include out-of-state opportunities? Or are you tied down, where you are? The job market for tech workers has been so hot that I find this surprising.

                Did you ever get any feedback from interviewers about what you could do to makes yourself more a compelling candidate? Do you have any more successful friends or trusted acquaintances who could review your resume for red flags?

                Comment


                • #98
                  Who?!!

                  Comment


                  • #99
                    Originally posted by coder View Post
                    Did your job search include out-of-state opportunities? Or are you tied down, where you are? The job market for tech workers has been so hot that I find this surprising.

                    Did you ever get any feedback from interviewers about what you could do to makes yourself more a compelling candidate? Do you have any more successful friends or trusted acquaintances who could review your resume for red flags?
                    At first it was a local job search but now it is a multi state. I'm currently searching for a job as a junior system administrator. I know a few other people who got jobs, two guys in my program got defense contractor jobs.

                    Comment


                    • Originally posted by kylew77 View Post
                      At first it was a local job search but now it is a multi state. I'm currently searching for a job as a junior system administrator. I know a few other people who got jobs, two guys in my program got defense contractor jobs.
                      If it interests you, consider looking in adjacent fields. Dev Ops seems have really heated up, in recent years. There might be something in quality assurance, such as writing automated tests, which plays into your strengths. If you enjoyed your time with students, there could be some opportunities in training, also. My company deploys and services Linux-based appliances and has field techs who basically just have a Linux sysadmin type skill set. Another example might be installers of on-prem network-based equipment. Just a few examples.

                      I guess, what I'm saying is that you could be limiting yourself. If you think "inside the box", you pretty much know the best case scenario. If you think more laterally, you might find some surprises. Also, don't be afraid to take a chance on a couple startups, early in your career. The older you get, the harder it becomes to take on the risk.
                      Last edited by coder; 13 September 2022, 02:21 AM.

                      Comment

                      Working...
                      X