schlupa

and

     *((char*)mempcpy(dst, src, min(len, dstsize-1))) = 0;

can be replace by

     ((char*)memcpy(dst, src, min(len, dstsize-1))[min(len, dstsize-1)] = 0;

if you don't have mempcpy

It's 4 lines of code to implement it. So even if it is not available on a platform (glibc mmmh because of Dreppers stubborness), it's no problem.

    size_t strlcpy(char *dst, const char *src, size_t dstsize)
    {
       size_t len = strlen(src);
      if(dstsize)
        *((char*)mempcpy(dst, src, min(len, dstsize-1))) = 0;
      return len;
    }

UCSD and Turbo-Pascal had it easy with the 255 byte strings. They had real strings but these were compiler extensions. Real Pascal didn't have string support and you could only work with packed array of chars of fixed size and as the language was extremely strong types, to packed chars types of different lengths were considered different types, so you had to write procedures and functions for all used packed array sizes.

Also most of the time people have serious performance regressions with strncpy() as the function overwrites with 0 all the test of the buffer.

     char buffer[2000];
     strcpy(buffer, "hello", sizeof buffer);

writes "hello" and 1995 0 to the buffer.

strncpy() suffers from its naming. It never was a string function in reality. It is a function to write and clear a fixed size buffer. It was invented to write filenames in the 14 character buffer of a directory entry in early Unix. It should have been name mem-something and people would have never come to the idea to use it for general string routines.

Ryzen 7 4750G (Matisse) is Zen 2

Only if the President is not Trump.

A restaurant is a private company and if they don't want to serve blacks and jews they can completely do it.

You see now how absurd that argument is?

What happens some times is that changes in the compiler fixes issues that were not well defined in the specification, or were bugs in the implementation. Programs that used the feature wrongly or that were in fact buggy then break when compiled with the better specified feature. It's comparable to compiling a K&R conforming C program with C89 or C99 enforcing: it will reveal bugs that were none in K&R (type punning, uninitialized variable, prototype violations, etc.).

Length (as proxy of expressiveness) of variable name should be a function of the scope of the variable. It there are only a few lines between declaration and last use of a variable a single letter name is often suffcient (i,j,k for loop vars, p, q, r for pointers, l for length, n,m for upper bounds, a,b,c,t, etc. for temporaries. If the scope is over a longer section, without to much repetition it is appropriate to have a longer name. If it is a global variable with external linkage, it is very good to have a descriptive name so that it is also clear what it is when looking from outside.

What an utter bullshit article. If people can't see the technical merit of an article past the swear words, they should stop working and join their convent of choice. Weaklings.

It is a fuck up. Ignoring a sequence point (function call) is serious business. Probably a too agressive inlining.

Thank you for your tips. It's a pity that this information is not very visible on the quick start page.

llvm+clang v10 on Linux builds 8 GB in bin, 13GB in lib and >5 GB in tools + things here an there. That's ~30 GB. Then you need that much for the install. So hard requirement 2 x 30 GB + some slack. Last time I built it was around version 4 and it did not need that much disk space.

That's what building from source builds by default. I limited the build to X86, I don't need the cross compiling capacity There's probably a combination of options that will reduce the sizes and such, but by default it's gigabyte big binaries statically linked.

I do not choose the hardware (big bureaucratic organization). I will try the LLVM_LINK_LLVM_DYLIB and LLVM_BUILD_LLVM_DYLIB options next time. By default it builds static binaries and libraries requiring gigabytes of disk space.

A shared object, even if mapped in 300 running apps will be loaded only once in physical memory (at least for the code segment). Statically built binaries will have each another copy of the code that will be loaded every time the binary is started. So it will be loaded in memory 300 times.

I just checked the size of the clang-10 binary that was built. It is fucking 1.9 GB big (gcc 9.2 on the same machine is 6.1 MB).

Building llvm+clang from source is also ludicrous. 70 GB of diskspace usage and takes an hour to build, ridiculous. It's the static linking which is the culprit here, hundred of MB big binaries are a catastrophe for cache and memory subsystem. The funny thing is that my project also uses modules in D. Building the D compiler takes 10 seconds including unpacking of the tarball.

65C816 and also Motorola 6809 could set any page as 0 page (called direct page).

The 8 Bit guy builds a new computer around it. https://www.facebook.com/groups/CommanderX16/

Nope. Most modems used in the '90s using the Rockwell chipset used a 6502 derived controller which was clocked at over 60 MHz. The NDA we had to sign to get access to the source code (to just modify some strings) was from another world and that's probably why it is not a very known fact.

Don't bother, it's the narcissist KingJoffrey who got no traction in the forum with his complaint of private access at module level. He shows all the symptoms of narcissism like "exaggerated feelings of self-importance, excessive need for admiration, and lack of empathy". They also are feel entitled and vindictive so they don't hesitate to use unethical behavior for vengeance, like using fake accounts to post garbage (he had even posted under your name). So be careful, I don't know what we can do against that but awareness is imho at least a start.

Here the list of traits that could be observed in the private complain thread:

- Grandiosity with expectations of superior treatment from other people - Fixated on fantasies of power, success, intelligence, attractiveness, etc. - Self-perception of being unique, superior, and associated with high-status people and institutions - Needing continual admiration from others - Sense of entitlement to special treatment and to obedience from others - Exploitative of others to achieve personal gain - Unwilling to empathize with the feelings, wishes, and needs of other people - Intensely envious of others, and the belief that others are equally envious of them - Pompous and arrogant demeanor

Oh, look the annoying D forum troll KingJoffrey / DigitalDesigns / many other sock puppets.

or simply to have control over the code.

May be. TI BASIC was also limited in a lot of other ways. It didn't have ELSE and the THEN clause didn't allow for anything other than a line number as jump destination. Only one statement per line. So doing something as simple as 10 IF a=1 THEN v=10 ELSE v=50 would have to be written as 10 IF a=1 THEN 40 20 LET v=50 30 GOTO 50 40 LET v=10 50 ...

This was IMHO the worst restriction of that BASIC.

The only feature on the plus side of that BASIC was that it used the BCD floating format they also used in their calculator. So 13 digits precision with numeric range of 10^-99 to 10^99. When I switched later to the Apple II, I was shocked at the ridicule binary floating point format that couldn't even add 2 simple numbers correctly :-)

The TI-EXTENDED BASIC was an absolute must if you wanted to do serious programming. It enabled the sprites, had fancy stuff like named subroutines (that could even be called recursively) and a lot of restriction of the original BASIC were lifted.

The Basic was slow for several reasons. 1. Double interpretation: As other already pointed out, the interpreter was written in an interpreted language, a kind of byte code if you prefer. 2. GROM routines: What added to the pain was that a lot of the routines necessary for the program were not in ROM but in TI specific GROM. All the "CALL something" (CALL CHAR, CALL HCHAR, CALL VCHAR, CALL SOUND, etc.) commands were GROM routines. GROM were a kind of serial ROMS that only TI manufactured (one of the reasons third parties had such a struggle with that machine). 3. VRAM: the worst offender why TI-BASIC (and TI-EXTENDED-BASIC) were so slow was that the basic console only had a wopping 256 bytes of memory. Yes, you read it right, the CPU only had 256 bytes of fast 16 bit memory. This memory was used by the system and were not accessible to the programmer. So where was the BASIC code then? It was stored in the video RAM and the CPU had no direct way to read and write to it. It always had to go through the TMS9918 video chip. This has 2 consequences, it was obviously slow and it clogged the video RAM. So unless one bought the 32K RAM expansion (which was outrageously expensive) or the mini-memory module (but then no Extended Basic was possible) it was impossible to use the graphic modes, making that incredibly advanced graphic chip a dud.

It's probably the strangest machine (aka f..d up) of the home computer era.