Announcement

Collapse
No announcement yet.

Fedora 29 Dropping GCC From Their Default Build Root Has Been Causing A Heated Debate

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

  • #21
    Originally posted by Weasel View Post
    But the Linux userland violates the language specification, especially for C++. It is so dependent on the exact standard library implementation of GCC and other GCC features that it can lead to many problems mixing compilers up.
    To give some context, this is just keeping alive the old ways they had when C++ was a clusterfuck of competing "standards" and any compiler did whatever the fuck it wanted to.

    This is one of the main reasons Torvalds refused to accept C++ in his kernel back then. Because there wasn't just a C++.

    Now C++ is more unified, but changing old codebases is not really feasible, and in the meantime it snowballed and grew into its own subculture.

    technically it's illegal even there though, it's just not a practical issue, but it still breaks "standards")
    Technically breaking a standard isn't illegal, so calm yo tits a bit there.

    Cops won't show up on FSF door to convict them for their "allowing illegal c++ usage in their compiler" anytime soon.

    Note that it's not really the kernel's fault whatsoever, so it's not Linux per se, just the userland libraries. Linux (the kernel) is still solid as ever.
    No duh. The Kernel is in C. C has no concept of objects at all.

    Comment


    • #22
      Originally posted by starshipeleven View Post
      Technically breaking a standard isn't illegal, so calm yo tits a bit there.

      Cops won't show up on FSF door to convict them for their "allowing illegal c++ usage in their compiler" anytime soon.
      Legal has more meanings than just social law.

      In fact, a "language lawyer" is a perfectly known term for a programming language and describes a person which knows the programming language to the tiniest of details (which is a large feat for C++, not so much for C).

      I mean the context was that "GCC breaks standards" (i.e. C/C++ language rules) so illegal was in that context obviously. Not that they end up in jail over it.

      Comment


      • #23
        Originally posted by Weasel View Post
        I don't know what libraries, it wasn't me who said that libraries should do that. I've only ever used sane libraries with symmetrical API designs, so I can't say (again, it wasn't me who said they use that, but people defending them)

        Strings are not a "C type", they're just a region of bytes as implied by const char*. That is, they're not a specific special type like C++ std::string or whatever. It's not the type itself that's the problem in this case (basic types are perfectly fine to use), it's the allocation. You simply don't allocate stuff in a library and expect something else to free it without going through your library.

        malloc is a function. A function with a specific data structure (the structs used on the heap) and other stuff like that. Why on earth would people think that it's a good idea to use malloc from a library (using a specific function and its specific data structures) and then let *someone else* free it, when there's NO GUARANTEE by the language that it's the same implementation. In fact the language doesn't even define an implementation of malloc, at all.

        In most cases, you don't even control what standard library you link to with a compiler, so you cannot ENFORCE the fact that it's the exact same function. Thus, it is a violation of the language rules (ODR).

        "Oh but on Linux everyone compiled with GCC and it's a de facto standard and blabla" -- well that's... kind of the point... I was making, and why this decision is dumb until Linux userland becomes sane.


        tl;dr Clang and GCC just happen to use the same C library, but not C++. "Just happen" doesn't mean it's respecting the language, it's not any different than relying on "specific compilers".
        C strings have been a "type" since the day the strxx() functions where added to the K&R C which is since day one, also both malloc() and free() have been part of the std lib since the day K&R invented the language. The stdlib is part of the language weather you like it or not. Have you even read the K&R?

        Clang and GCC does not use the same C library by pure chance, it's by design. This is only a problem on Windows since Microsoft decided to have 4 different versions of libc as part of Windows since Windows 95 and then 2 new versions for each version of VisualStudio since VS7.0.

        Unix have always had a single libc throughout the entire system, systems like Alpine that use musl instead of glibc does not mix and match, the entire distribution is linked with musl.

        And of course you can control which stdlib you link with in "most cases", it would take a very special obscure compiler to remove that functionality.

        Comment


        • #24
          Originally posted by F.Ultra View Post
          C strings have been a "type" since the day the strxx() functions where added to the K&R C which is since day one, also both malloc() and free() have been part of the std lib since the day K&R invented the language. The stdlib is part of the language weather you like it or not. Have you even read the K&R?
          You're missing the point. Their implementation is not part of the language. The language does not enforce their implementation to be the same on a platform or anywhere.

          Their interface and behavior (what they do) is part of the language, but their implementation is not. So you should not ever mix an allocated region from one malloc with a free imported by a different thing -- there's simply no guarantee by the language that they share the same data structures and implementation, internally.

          Yes it's by design they use the same libc, but not by the design of the language, which was the context here. "GCC and Clang" breaking standards and all by relying on this (standard = language in this context; but GCC is the "standard" in current userland, hence why I find it stupid you have to be explicit; it's stupid to be explicit about THE STANDARD, because GCC is the standard, currently).

          Comment


          • #25
            Originally posted by F.Ultra View Post
            C strings have been a "type" since the day the strxx() functions where added to the K&R C which is since day one, also both malloc() and free() have been part of the std lib since the day K&R invented the language. The stdlib is part of the language weather you like it or not. Have you even read the K&R?
            Ehh, on that point I'm with Weasel. Just because a bunch of functions all operate on blocks of bytes does not make those memory regions anything more than that, and certainly it doesn't make them a string "type" by any stretch. Even before the advent of Unicode and the arrival of variable-byte-length encodings, *char[] was not a string type, and couldn't be treated as a string type. Mostly because char is not really a character type — char represents a byte. There are hardly any characters that will fit within a single byte. (Only 255, when there are over 65k in Unicode's Basic Multilingual Plane alone.) Anyone who tried to pretend otherwise would eventually be taught a painful lesson in why clever fictions don't really feel very clever at all, once they're biting you on the ass.

            Not to say that I agree with Weasel's larger r̶a̶n̶t̶ point, or that I don't think the issues are being blown out of proportion from their end. But it's possible to exaggerate in more than one direction, and anyone who handwaves, "Oh, C has a string type, just look at the strwhatever() functions in libc" is either grossly misrepresenting the situation, or has grossly misunderstood it.

            Are there really still programmers who consider an array of "characters" (bytes!) to be a "string", or think they can do 1990s-era pointer arithmetic to manipulate the contents? Does anyone still believe the K&R-era "string" functions like strncpy() and strchr() have a place in the 21st Century, or doubt that they carry the risk of horribly mangling any string containing non-ASCII characters? (Which, now that the entire world consists of more than just the United States ca. 1983, you should assume every string does!) That delusion is the path to a future filled with reams of line noise and endless garbled filenames.

            If you still believe that char* is a "string" and strnchr() can be used to extract substrings from it, find Joel Spolsky's "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)"

            Before I end this overlong digression, allow me to quote from Spolsky, even though it's admittedly a bit off the topic of string storage in memory:
            The Single Most Important Fact About Encodings

            If you completely forget everything I just explained, please remember one extremely important fact. It does not make sense to have a string without knowing what encoding it uses. You can no longer stick your head in the sand and pretend that “plain” text is ASCII.

            There Ain’t No Such Thing As Plain Text.

            If you have a string, in memory, in a file, or in an email message, you have to know what encoding it is in or you cannot interpret it or display it to users correctly.
            ...Turns out "strings" are a whole lot more complicated than Kernighan, Ritchie, Thompson, Knuth, Dijkstra, et al. ever imagined. Alan Kay might be the only one who really had a glimpse of the future, even way back then.

            Comment


            • #26
              This just means the package developer needs to specify that gcc or g++ is required, it does not mean they are unavailable, right?

              If so then this really is 'nothing to see here, move along'.
              Last edited by hoohoo; 12 July 2018, 04:51 PM. Reason: typo

              Comment


              • #27
                Originally posted by FeRD_NYC View Post

                Ehh, on that point I'm with Weasel. Just because a bunch of functions all operate on blocks of bytes does not make those memory regions anything more than that, and certainly it doesn't make them a string "type" by any stretch. Even before the advent of Unicode and the arrival of variable-byte-length encodings, *char[] was not a string type, and couldn't be treated as a string type. Mostly because char is not really a character type — char represents a byte. There are hardly any characters that will fit within a single byte. (Only 255, when there are over 65k in Unicode's Basic Multilingual Plane alone.) Anyone who tried to pretend otherwise would eventually be taught a painful lesson in why clever fictions don't really feel very clever at all, once they're biting you on the ass.

                Not to say that I agree with Weasel's larger r̶a̶n̶t̶ point, or that I don't think the issues are being blown out of proportion from their end. But it's possible to exaggerate in more than one direction, and anyone who handwaves, "Oh, C has a string type, just look at the strwhatever() functions in libc" is either grossly misrepresenting the situation, or has grossly misunderstood it.

                Are there really still programmers who consider an array of "characters" (bytes!) to be a "string", or think they can do 1990s-era pointer arithmetic to manipulate the contents? Does anyone still believe the K&R-era "string" functions like strncpy() and strchr() have a place in the 21st Century, or doubt that they carry the risk of horribly mangling any string containing non-ASCII characters? (Which, now that the entire world consists of more than just the United States ca. 1983, you should assume every string does!) That delusion is the path to a future filled with reams of line noise and endless garbled filenames.

                If you still believe that char* is a "string" and strnchr() can be used to extract substrings from it, find Joel Spolsky's "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)"

                Before I end this overlong digression, allow me to quote from Spolsky, even though it's admittedly a bit off the topic of string storage in memory:


                ...Turns out "strings" are a whole lot more complicated than Kernighan, Ritchie, Thompson, Knuth, Dijkstra, et al. ever imagined. Alan Kay might be the only one who really had a glimpse of the future, even way back then.
                Hence I enclosed the word type with quotes as in "type". If we can leave semantics aside (I mean WTF), this is all irrelevant since what ever you want to call a stream of zero terminated bytes that you allocate with malloc() and free with free() still does not need a library specific library_free() function unless it's used on a platform where you will have a mixed set of libc:s which you have on Windows.

                And yes you can use char * as a string and any of the strxxx() functions with UTF8 (which have been the Linux default for many many years now) without any problems whatsoever as long as you make sure to rewind or forward to the next possible start of a multi-byte character if you need to manipulate the string.

                Here in Europe we have programmed for different locales for decades.

                And 1990-style pointer arithmetic :-) We did that back in the 80:ies and K&R did it in the 70:ies if not earlier. Nothing wrong with that either today as long as you know what you do.

                Not sure if you really have read Joels article that you quoted from since there is nothing in it that contradicts anything that I just wrote. If your source is anything but utf-8, convert it with iconv() and after that you can manipulate it like it was 1978 (with one small caveat).

                Comment


                • #28
                  Originally posted by hoohoo View Post
                  This just means the package developer needs to specify that gcc or g++ is required, it does not mean they are unavailable, right?

                  If so then this really is 'nothing to see here, move along'.
                  Yes but some are complaining that if they one day would switch to Clang then having gcc here would require a massive change then

                  Comment


                  • #29
                    Originally posted by Weasel View Post
                    You're missing the point. Their implementation is not part of the language. The language does not enforce their implementation to be the same on a platform or anywhere.

                    Their interface and behavior (what they do) is part of the language, but their implementation is not. So you should not ever mix an allocated region from one malloc with a free imported by a different thing -- there's simply no guarantee by the language that they share the same data structures and implementation, internally.

                    Yes it's by design they use the same libc, but not by the design of the language, which was the context here. "GCC and Clang" breaking standards and all by relying on this (standard = language in this context; but GCC is the "standard" in current userland, hence why I find it stupid you have to be explicit; it's stupid to be explicit about THE STANDARD, because GCC is the standard, currently).
                    You are still having your head in Windows-land here. There is no "one malloc with a free imported by a different thing", they cannot be imported by different things because there can not exist another libc! You might not like that but that is how it works on Linux, BSD and most of the other Unixes (writing most here since I do not have experience with every single one).

                    Comment


                    • #30
                      Originally posted by F.Ultra View Post
                      You are still having your head in Windows-land here. There is no "one malloc with a free imported by a different thing", they cannot be imported by different things because there can not exist another libc! You might not like that but that is how it works on Linux, BSD and most of the other Unixes (writing most here since I do not have experience with every single one).
                      Absolutely nonsense. Show me the promise or law that prohibits Linux from using another libc. Not to mention that this is not part of the LANGUAGE which was the context. It's not a contract enforced by the language (i.e. "thou shall not use any other libc on Linux").

                      https://stackoverflow.com/questions/...-a-single-host

                      Keep in mind that an executable can link to a different loader or libc than one of its dependencies (libraries). The kernel does support multiple libc (other than glibc) that's why even its libc syscall interface is stable in the first place, to support alternative libc like MUSL. (apparently some distros even use musl as default, imagine if you try to use a library compiled for another distro and you supply all the dependencies... yeah, on Windows this is no problem due to better DLL design, on Linux they break standards and language rules left and right, assume GCC, etc, so fiasco ensures)

                      We have to remember that just because something happens in your particular case and distro/system does not make it a fact.
                      Last edited by Weasel; 13 July 2018, 08:33 AM.

                      Comment

                      Working...
                      X