The Linux Kernel Is Now VLA-Free: A Win For Security, Less Overhead and Better For Clang (phoronix.com)

With the in-development Linux 4.20 kernel, it is now effectively VLA-free. From a report: The variable-length arrays (VLAs) that can be convenient and part of the C99 standard but can have unintended consequences. VLAs allow for array lengths to be determined at run-time rather than compile time. The Linux kernel has long relied upon VLAs in different parts of the kernel -- including within structures -- but going on for months now (and years if counting the kernel Clang'ing efforts) has been to remove the usage of variable-length arrays within the kernel. The problems with them are:
1. Using variable-length arrays can add some minor run-time overhead to the code due to needing to determine the size of the array at run-time.
2. VLAs within structures is not supported by the LLVM Clang compiler and thus an issue for those wanting to build the kernel outside of GCC, Clang only supports the C99-style VLAs.
3. Arguably most importantly is there can be security implications from VLAs around the kernel's stack usage.

Comments

"VLAs within structures" not part of C

[Anonymous Coward]

VLAs within structures ... are not supported

Wut?

Flexible array members are part of the C standard:

6.7.2.1 Structure and union specifiers

...

18. As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. In most situations, the flexible array member is ignored. In particular, the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply. However, when a . (or ->) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed; the offset of the array shall remain that of the flexible array member, even if this would differ from that of the replacement array. If this array would have no elements, it behaves as if it had one element but the behavior is undefined if any attempt is made to access that element or to generate a pointer one past it.

...

Or maybe they're referring to something else?

Re:"VLAs within structures" not part of C

[Knuckles]

VLAs within structures ... are not supported

Maybe read the whole sentence?

Re:"VLAs within structures" not part of C

[aardvarkjoe]

This is what they are referring to. Code like (from that link):

void
foo (int n)
{
  struct S { int x[n]; };
}

Re:"VLAs within structures" not part of C

[Anonymous Coward]

Looks like you are lost, buddy. This is C.
And how does your vector BS solve the problem? Is its storage allocated on stack entirely?

Re:"VLAs within structures" not part of C

[Anonymous Coward]

std::vevtor is never the sensible thing to do.

Re:"VLAs within structures" not part of C

[Anonymous Coward]

"Is it more powerful?"
"The dark side is quicker, easier, more seductive."

My thoughts on working on a project someone else abused those on.

Re:"VLAs within structures" not part of C

[Anonymous Coward]

Getting C++ run-time working in kernel mode is a lot of work (as L4Ka:Pistachio and the Zircon microkernel already know). Getting a C++ based kernel working is potentially more work than writing a kernel in C, depending on if you're willing to tolerate an incomplete subset of real C++.

Re:"VLAs within structures" not part of C

[The Evil Atheist]

std::vector uses the heap. VLAs are supposed to be on the stack, or at least without require separate allocation. You can't use the heap to solve all your problems when it comes to a kernel.

Re:"VLAs within structures" not part of C

[Darinbob]

Sadly I knew someone who prefered std::map over std::vector. Including when the key range was tiny and it was guaranteed to only have a single element at a time (I so wish I was making this up). If someone's only tool in their tool box is an nail-gun, don't be surprised if their project has a lot of nails in it.

Re:"VLAs within structures" not part of C

[Darinbob]

Generally, you can get the tricky parts of the kernel done in C, then layer C++ on top of it. That's what a lot of embedded RTOS systems do. The biggest snag is the tendency of getting bloated code from developoers not aware of what C++ does behind the scenes.

Re:"VLAs within structures" not part of C

[epine]

I just read a few things about VLAs in C99, and my god, it makes Stroustrup look like a rocket scientist.

Convenient while it works, then brutally unsafe the moment it doesn't work (recompile for a new platform, whole new stack-size ballgame—you do the math, except you can't, because the C standard is deaf-mute on the existence of the primary stack, and hence, perforce, also its size limits).

Of course, when you're compiling the Linux kernel, you are compiling the platform itself, so internally it can certainly sort things in a way that an ordinary C program probably couldn't.

But still, I can't recall C++ violating the type system / allocation sanity this badly since vector<bool> was originally defined as a specialization that didn't actually meet the vector<> container class conceptual requirements, or maybe some early, misguided implementations of smart pointers (who precise misfeatures I've now blissfully forgotten).

Re:"VLAs within structures" not part of C

[Uecker]

Huh? There is nothing unsafe with VLA. They also tend to *reduce* stack usage, as the alternative are oversized fixed size arrays on the stack. If you care about the dynamic sized stack, then you also can't have functions calls in a conditional path.

Re:"VLAs within structures" not part of C

[Anonymous Coward]

because the C standard is deaf-mute on the existence of the primary stack, and hence, perforce, also its size limits).

I like to program on a system that is very memory limited and hence also stack limited.

Pretty much every high level language except C99 is a no-go.

Pretty much every other languages solution is "Nah, don't worry about it".
Good luck trying to write C++ without dynamic memory allocation while trying to predict how much stack it will use.

Re:"VLAs within structures" not part of C

[Anonymous Coward]

This is what they are referring to. Code like (from that link):

void
foo (int n)
{

  struct S { int x[n]; };
}

Would the fix be replacing that with a pointer and calling malloc()?

Re:"VLAs within structures" not part of C

[jeremyp]

The flexible array member of a struct is not the same as a variable length array.

Re:"VLAs within structures" not part of C

[religionofpeas]

They reduce average stack size. They don't reduce the worst case stack size, which is what you care about.

Re:"VLAs within structures" not part of C

[Joce640k]

It's almost as if you don't know that std::vector can use a custom memory allocator, eg alloca().

Re:"VLAs within structures" not part of C

[Joce640k]

The biggest snag is the tendency of getting bloated code from developoers not aware of what C++ does behind the scenes.

Doesn't the Linux kernel have a whole army of people approving code changes? They could be aware of what C++ does behind the scenes even if the developers aren't.

(But seriously: Do you think a Linux core developer is incapable of using C++ properly or knowing what it does behind the scenes?)

Re:"VLAs within structures" not part of C

[Anonymous Coward]

Most of the contributions to the Linux kernel are done by people with little day to day C++ experience. They aren't really capable of producing reliable C++ code without a whole lot more practice.

Linux is a C project. End of story. If you want to work on a C++ project go join Haiku or something.

Re:"VLAs within structures" not part of C

[Anonymous Coward]

I always thought that people liked to allocate arrays on the stack because it made memory management easier: returning from the function automatically frees memory without having to do this in every place you can return from. The STL examples here are really just a different way to skin the same cat, whether it's a vector or just one of the *_ptr objects.

Re:"VLAs within structures" not part of C

[Uecker]

They can reduce max stack size in come cases. E.g. if you split one array into two smaller arrays but you don't know how big the smaller arrays are. In any case, they never increase stack size when compared to static arrays on the stack.

Re:"VLAs within structures" not part of C

[Darinbob]

I was referring to kernel and OS work in general, not Linux specifically.

Re:"VLAs within structures" not part of C

[The Evil Atheist]

It's almost as if you don't know that alloca isn't safe. Especially with vector, resizing is very dodgy with alloca. You may as well just use a std::array.

Re:"VLAs within structures" not part of C

[Anonymous Coward]

It's almost as if you don't know that std::vector can use a custom memory allocator, eg alloca().

Don't be a dick...

However, it is not Code of Cancer-free.

[Anonymous Coward]

However, it is not Code of Cancer-free.

Bummer.

[demon driver]

Vla

Finally!

[nospam007]

"The Linux Kernel Is Now VLA-Free: "

It was already DDT-free, BPA-free and now also VLA-free, so it can be safely used at last?

Re:Finally!

[slickwillie]

But it is not TLA (Three Letter Acronym) free.

I think the Linux community should join CAT - the Campaign to Abolish TLAs.

Re:Finally!

[Spacelem]

Acronyms are words that you pronounce, like laser (Light Amplification by Stimulated Emission of Radiation), scuba, radar, or PIN (Personal Identification Number number).

Initialisms are words you spell out, like FBI, CIA, DNR, ECG, MRI, DVLA etc.

A TLA is an initialism, not an acronym, so really it's not a TLA, it's a TLI. Not sure which one CAT is supposed to be though!

Re:Finally!

[sexconker]

Your distinction is false. FBI, CIA, etc. are all acronyms. They're just abstracted names. Acronym literally means high name.

The term "initialism" is bullshit. It was bandied about in the late 1950s by some clown trying to foist your ridiculous distinction on the world. No one bought into it, nor should they have. The word "initialism" was already in use well prior, referring specifically to authors names.

Re:Finally!

[Anonymous Coward]

You lost all credibility when you said personal identification number number.

Re:Finally!

[Anonymous Coward]

Maybe this site explains the differences between acronym and initialism better that yours.

Re:Finally!

[Spacelem]

That was clearly intentional and meant as a joke, since everyone says "PIN number" all the time instead of just "PIN".

It's a case of RAS syndrome (or is it RIS syndrome?)

Re:Clang

[Mark Pitman]

YES!

VLA-free does not resolve the problem.

[Anonymous Coward]

The advantage of VLA is pushing items to it without knowing the max. capacity.

The risk of VLA-free is out of capacity, unknown max. capacity.

The stack is like VLA but for only 1 stack instead of many stacks as many VLAs.

Another example, the number of open files. I should not limit it to a small constant, by example, max. 1024 open files, but i need 1 million of open files (for P2P). With VLA it is more flexible under demand or needness.

Many current PCs are 64-bit and have much memory as 32 GB by example for preventing the bottleneck or the out of memory.

Re:VLA-free does not resolve the problem.

[drnb]

Another example, the number of open files. I should not limit it to a small constant

There is no such limitation. You can re-allocate arrays as needed. VLA is just automating that for you.

GCCisms

[jd]

The first problem is that they can be dropped from future versions of GCC. They're not part of any standard, after all.

The second problem is that there are situations in which GCC isn't the most suitable compiler. You want to minimize hacks for each different compiler supported.

Security is a big thing, too. It's hard to audit fundamentally unpredictable code.

A major step forward.

Re:GCCisms

[Anonymous Coward]

Once they can compile with clang, I predict that they'll suddenly have an urgent need to patch thousands of exploitable defects uncovered by clang tools (e.g. clang-tidy and UBSAN).

Re:GCCisms

[The Evil Atheist]

VLAs are part of the C99 standard. It says so right in the summary, and you can look up the standard itself.

Re:GCCisms

[The Evil Atheist]

GCC already supports many of Clang's sanitizers.

Re:GCCisms

[Anonymous Coward]

A major step forward.

How the fuck is this a step forward?

You previous needed a array of variable size.
You had a language feature that automatically allocated storage for it statically on the stack in a virtually seemless way.
"Oh no! Advanced features!! Memory stuff!! Scary, scary, go back to K+R!"
Great. Now you still need the same functionality , but you've now gone BACK to playing around with malloc/free, adding additional function parameters, wasting memory "just in case", or whatever other ad hoc solution a developer now has to use as a workaround.

New features are not just for convenience. They are often a direct response to serious, chronic deficiencies in the existing standard. Memory management is an eternal source of error an removing variable length arrays just leads to more of it.

"I'll just allocate all my arrays statically anyway. I know the right size in advance".
Great. Good for you. Master design. Except until the day a kernel module won't know the right size to allocate, and will call a function with enough instances that someone will go reaching for kmalloc instead. How many steps forward will you be then?

Re:GCCisms

[Anonymous Coward]

There are reasons many compilers never even implemented VLA, despite being part of the standard, and why C11 all but removes support.

VLA was "seamless" only by ignoring the error condition where there isn't enough stack and having no recovery mechanism from that. Allocation on the stack is usually a mistake, and even when it is not, you want to be more careful there - VLAs hide too much and look too natural.

Re:GCCisms

[Uecker]

VLA are part of the standard and it is a myth that removing them it helps security as it removes price information about run-time bounds from the compiler's view. In my opinion not using VLA is a major step back for security. (Yes, I contributed to with this overall effort myself, but only where it were fake VLAs which really had a constant size but the compiler couldn't know this).

For GNUisms in general, we will certainly try to standardize some of them (those which are useful, well-defined, and supported by other compilers).

Re:GCCisms

[jd]

The estimated defect density is around 0.014 (ie: about 14 issues per million lines of code). That gives you an upper threshold on exploitable defects.

However, if we can reduce that to 0.001, through Clang, which implies 325 defects found with Clang, I'm not going to complain. I'm going to cheer.

Re:GCCisms

[jd]

There's lots of stuff in the Linux kernel that uses a GNU variant of a concept rather than the ISO variant. Often because GNU was there first. If you switch from the vendor-specific form, the isms, to the standard form, you don't change the concepts involved but you do make it more portable.

Re:GCCisms

[jd]

1. Calm down
2. You're assuming GNU's method is the only method and thus the standard method
3. Plenty of people staple together blocks to create virtual arrays. Some are called filing systems, some are called Linux memory managers, and there's one called GMP. It's the method underlying any potentially fragmented workspace if you don't want to keep copying. Because it's required in a lot of Linux, a standard, portable, form in a helper library would be nice. It might mean we can get rid of the umpteen queue and stack implementations, too.

Re:GCCisms

[jd]

So you're aware that GNU introduced features often way in advance of any standard and that the GNU syntax/semantics don't always match the ISO version.

Let's see what ISO says about VLAs:

C99 adds a new array type called a variable length array type. The inability to declare arrays whose size is known only at execution time was often cited as a primary deterrent to using C as a numerical computing language. Adoption of some standard notion of execution time arrays was considered crucial for C’s acceptance in the numerical computing world.

Does this match your experience?

Would discontiguous pools of contiguous memory, giving you the ability to make anything flexible size, be that much worse as that's what the compiler will be using anyway?

Re:GCCisms

[vbdasc]

The first problem is that they can be dropped from future versions of GCC. They're not part of any standard, after all.

IMHO, GCC rarely drops its proprietary extensions, once introduced and documented. Correct me if I'm wrong.

Re:GCCisms

[Uecker]

So you're aware that GNU introduced features often way in advance of any standard and that the GNU syntax/semantics don't always match the ISO version.

Yes of course. In fact, I added myself a GNU extension. I am also participating in WG14.

Let's see what ISO says about VLAs:

C99 adds a new array type called a variable length array type. The inability to declare arrays whose size is known only at execution time was often cited as a primary deterrent to using C as a numerical computing language. Adoption of some standard notion of execution time arrays was considered crucial for C’s acceptance in the numerical computing world.

Does this match your experience?

Absolutely. I use C for numerical computing and VLAs a very important.

Would discontiguous pools of contiguous memory, giving you the ability to make anything flexible size, be that much worse as that's what the compiler will be using anyway?

I don't understand what you are trying to say. The VLA will live on the stack or the heap depending on where one allocates it. In both cases, there is no way to resize it. Making it resizable is much harder and no compiler does this as it would require a level of indirection which reduces performance and would require some kind of automatic memory management (automatically running destructors). Of course, you can always add your own abstraction for resizable arrays.

Re:GCCisms

[Uecker]

If you don't want to allocate on the stack you can also not call a function as the stack frame is allocated on the stack...

High vs low languages.

[HeckRuler]

VLAs are an example of C becoming ever so slightly higher level. When the language does things under the hood without telling you it's just an invitation to bite you in the ass. Good purge.

Re:High vs low languages.

[MobyDisk]

What was it doing under the hood without telling you? Isn't a VLA basically just a call to alloca()?

Re: High vs low languages.

[Anonymous Coward]

No it's not. VLA's expose a fundamental capability of the processor model - the fact that stack frames do not require a predetermined size. Without VLA's you leave this capability hidden.

Exposing these sorts of capabilities to the programmer is what C is about. If you don't like them then don't use them. Same could be said of function pointers.

Re:High vs low languages.

[HeckRuler]

Yes. Exactly that. It's allocating space for you. It figures out at run-time the length of your array rather than you having to do it by hand at compile-time. I didn't actually know of any security flaws this would lead to, but it stops debuggers from knowing details about calls so it obscured some information from me and pissed me off once.

Re:High vs low languages.

[Anonymous Coward]

Calls to alloca() are explicit which makes them less hidden to human review. VLAs encourage writing code without putting more thought into it. It also encourages the use of variably length things when fixed length things make more sense. It also discourages thinking about when variably length may come into play and how to efficiently handle them.

In general, all of this is bad things for code running at all times and with [near] unlimited power to do harm, especially when those properties are ripe for abuse by adversaries.

Re:High vs low languages.

[Anonymous Coward]

Given that alloca() is deprecated, it's not clear what the replacement is. Yes, I know the dangers of stack overflow. Still, it's sometimes handy to go quickly to the stack instead of to the heap.

Re:High vs low languages.

[Anonymous Coward]

So I assume you don't write in anything other than assembly then.

Re: High vs low languages.

[The Evil Atheist]

Stacks are an abstraction already. There's nothing fundamental about a stack.

Re: High vs low languages.

[Anonymous Coward]

C doesn't even require that the variables are allocated on stack.
Local variables are placed in automatic storage. It's up to the compiler where that is.
Some compilers use a separate variable stack to keep it away from the program stack.
Some compilers for microcontrollers without efficient stack pointer relative addressing checks for recursion and does static allocation if it can.

AFAIK there is nothing that prevents a compiler from doing a proper malloc() when VLA is used.

Re:High vs low languages.

[Anonymous Coward]

alloca() is deprecated because it was replaced with VLA.

When it comes to stack overrun VLA is much less of a problem than allowing recursion.

Re:High vs low languages.

[Anonymous Coward]

It could be, it could also hide calls to malloc and free, since the standard does not specify how it is implemented and the alloca implementation could overflow your stack for large allocations. The standard even contains a note calling out possible issues with longjmp causing VLAs to leak memory (since it wouldn't call free in the malloc case). Basically you cannot rely on a specific implementation of VLAs and creating one uses the same syntax as fixed length arrays, so you might end up using one when you don't actually want one.

I think VLAs would have been a nice feature if they didn't use an accident prone way to decide between compile time length arrays and VLAs. As they are now they should be purged just to avoid issues with accidential VLAs.

Finally TFS helps with TFT

[fahrbot-bot]

I was thinking a different VLA and what the f*ck that had to do with the Linux kernel.

Re:Finally TFS helps with TFT

[93 Escort Wagon]

This monolithic kernel bloat simply has to stop...

Very sad.

[Anonymous Coward]

I always knew GCC has better taste.

Not me. I think of Klaang

[mschaffer]

Klaang from Star Trek: http://memory-alpha.wikia.com/...

Good for debugging too

[drnb]

It helps with debugging too. Build with two unrelated compiler systems and bugs that don't stand out in one may stand out in the other. And I am talking run-time errors not compiler warnings.

GNU'isms

[drnb]

Once we get rid of all the GNU'isms can we go back to simply calling it "Linux". ;-)

Re:GNU'isms

[jd]

The GNU over Linux refers to GNU userspace over Linux kernelspace. So a GNU userspace over OpenBSD would be GNU/OpenBSD. BSD/BSD is 1, since you're dividing by itself.

Non-standard language extensions

[Anonymous Coward]

When Microsoft adds unique features to their C/C++ compiler, the open sores crowd complains about "proprietary extensions" and insists on "standards conformance".

When the Linux kernel depends on non-standard language extensions that only GCC implements, that's OK.

Re:Non-standard language extensions

[arth1]

When the Linux kernel depends on non-standard language extensions that only GCC implements, that's OK.

Except that VLAs are part of the C99 standard, and there's nothing in the standard that says they can't be used in a struct - it's just difficult for the compilers. gcc has chosen to technically implement it as an extension, while Clang/LLVM doesn't support it (nor the floating point pragmas of C99, which has also been an issue for some kernel code).

Re: Non-standard language extensions

[Anonymous Coward]

This kind of BS is why we've had to endure java for so long. Undefined behaviour, non-portability and lack of security models.

Re: Non-standard language extensions

[The Evil Atheist]

It's not undefined. It's portable.

Re: Non-standard language extensions

[Anonymous Coward]

Used sanely Java isn't terrible. Even with realtime stuff - I had no problems. Just don't create objects in the critical path. Given the choice, I wouldn't choose to write the lowest levels of a kernel in Java (or C++) though.

The merit of variable length C99 arrays is a good question. My conservative side says just allocate fixed sized stuff for the smaller cases and for the others malloc and deal with it. If pointers to lists of structs scare you, C ain't for you. But FFS it's 2018 - Is it too much to ask for a C compiler with enough brains to handle VLA's well? I guess so!

I'd love to see some microbenchmarks of VLA's vs doing it the old way.

Re: Non-standard language extensions

[Anonymous Coward]

Except for the platforms that doesn't have the runtime environment, then it is by far easier to port C code.

If you want true "write once, run everywhere" you should write in 6502 assembly for the NES environment.
NES emulators exists for way more architectures than the Java emulator.

Re:MORE's coming that's cool... apk

[Anonymous Coward]

Your link may provide some links to interesting stories at Phoronix beyond what's posted in this Slashdot story: 1, 2, and 3. However, it would have been better to link directly to the Phoronix stories instead of your comments. Details are lacking in the Phoronix stories, such as why XArray was rejected for inclusion in the 4.19 branch. It is good to see improvements in the Linux kernel that result in cleaner and more secure code, like removing VLAs.

One criticism of Linux versus *BSD is that the *BSD kernel code is much cleaner and better written than many portions of the Linux kernel. Although it's good to see new features added to the Linux kernel, it's also very good to see efforts like this to clean up the existing code. For those who would say that *BSD code cleanliness comes at the expense of supporting newer hardware and features, there are also a lot more contributors (especially corporate contributors) to Linux than for the *BSDs.

By the way, this is the third time you've posted this comment. Even if your comment is on-topic, this is the third time you've posted the comment in this article. You have a tendency of doing this. Posting the same comment more than once makes any reports, by definition, redundant. The links are actually interesting, but you deserve your -1.

Oh, god, the kernel is already falling apart!

[shess]

See, adopting a code of conduct is already undermining the foundations of the kernel.

C does not really have arrays

[aberglas]

Just memory addresses. *Foo could be one or a few or many. Pointer arithmetic.

So variable arrays feels odd.

If you did not like chasing down weird memory corruption problems then you would not be using C (or C++) in the first place.

It would have been trivial to add a little bit of sanity with syntax like

void foo(char buf[blen], int blen)

so a compiler could, in debug mode, check. But no, that would not be a hero's C. nor is variable length arrays.

Incidentally, C's lack of arrays is not efficient. E.g. it is the reason we need 64 bit pointers, namely that C can only address 4 gig in 32 bit pointers. Java can access 32 gig of memory with 32 bit pointers because mallocs are aligned, and 32 gig is more than enough for the vast majority of current applications, and likely to remain so for a long time to come. Doubling your pointer size with lots of zeros is expensive, it clogs caches etc.

Re:C does not really have arrays

[Aighearach]

If you did not like chasing down weird memory corruption problems then you would not be using C (or C++) in the first place.

Well, perhaps but OTOH many of us avoid malloc like the plague.

Re: C does not really have arrays

[Anonymous Coward]

why the fuck are you coding in C then?

Re:C does not really have arrays

[jd]

Well, most machines probably do treat a machine-level 64-bit pointer as a 64-bit pointer if the opcode says to. It's an atomic operation to load into a register, after all.

In practice, the compiler won't use a 64-bit opcode if a smaller operation is faster and will work. One reason strongly-typed languages are good for optimizers - you can place things precisely and thus work out how large pointers need to be.

That's the compiler. The machine just runs the opcode as provided.

Re:C does not really have arrays

[Anonymous Coward]

You have been hacking C so long it has rotted your brain.

C only requires 64 bit pointers because it demands byte addressing, in turn because it does not have arrays. But most things are 64bit aligned. So that is how Java can work the magic. Because hardware has been tuned to run C, the opcodes themselves need to be 64bit. But in the data structures only 32 bits need be stored, and a simple shift performed.

Java can often be faster than C/++ in practice. Things like not copying malloced structures, and aggressively in lining code can beat typical C. And there is absolutely no way to implement Java style efficient garbage collection using C.

All = array variants? No

[Anonymous Coward]

See subject: Fastest things this machine understands IS a contiguous chunk of RAM array structure - linked lists "F" that up!

* I've heard it said "all things are array based" - bullshit. See above. Falls apart via pointer addresses all the FUCK all over. Does it work? Yes. Barely. It causes issues. These systems respond BEST to straight-up contiguous arrays in RAM.

Anything else? Bandaids (necessary but shitty).

FACT!

* You "F" memory up w/ enough pointer activity (especially w/ modern protective, yes good, mechanisms like ASRL)? It gets SLOPPY (just like a disk does fragmented - higher latency - imperceptible? BS - do it enough, it's HIGHLY perceptible).

Memmgt subsystem thrash (paging to disk = WORST latency).

APK

P.S.=> Good things coming for Linux goofs (me = one currently, BSD soon) offsetting SOME of it https://linux.slashdot.org/com... ... apk

Re:All = array variants? No

[jd]

Contiguous memory is the correct solution, yes. But nothing stops you having an index that tells you where the base is for a given offset. That lets you have a discontinuous set of arrays where each one is accessed as a contiguous array.

Examples: Memory pages in Linux.

If you go onto a different page, you have a different base address. But each page is contiguous. It works, we know it works, and except on crossing boundaries, it's t h e fastest method as you point out.

420 Blaze it!

[Anonymous Coward]

The 4.20 kernel is gonna be "blazingly" fast. Sure to be popular in Canada and parts of the USA. 4.20 blaze it!

VLAs shouldn't exist in C.

[Anonymous Coward]

What an awful feature. Almost as bad as auto.

Re:Purely arbitrary/personal BUT... apk

[Anonymous Coward]

Holy shit! You're an alchemist and conjuror too?

ALL HAIL APK!!! Our new God has risen.

Re:Clang

[Anonymous Coward]

> Is it just me, or so other people think of Krang whenever they see the world "Clang"?

No, but I sometimes think of this: http://www.subutai.mn/clang.ph...

Re: Clang

[joao.cordeiro]

Remember what the doctor said!

Re:You sure do... apk

[Anonymous Coward]

Zing! What a great comeback. APK, you sure told that guy with your anonymous posts.

ZIP

P.S. => Grow a fucking pair you tremendous tool.

ZIP you = "FORREST chump" w/ proof

[Anonymous Coward]

You're a BETTER programmer than I, quoted saying so below? WHERE'S PROOF OF WORK YOU DO EVEN /.ers LIKE & USE?

It's NOT!

"P.S. => I'm a much better programmer than APK, as has been proven." - by Anonymous Coward ZIP on Monday October 08, 2018 @11:27PM (#57449082)

FROM https://yro.slashdot.org/comme...

* I have DOZENS of /.ers saying they like & use my work - praising it & it's good effects on more speed, security, reliability & anonymity PLUS 100,000++ users of it worldwide - DO YOU??

HELL NO!

You also LIED trying to "take credit" for a SOLUTION to C++ string buffer overflow issues I SOLVED WAY BEFORE YOU https://tech.slashdot.org/comm... proof's right there scumbag punk you are.

I also shot you to pieces on your github LIE @ the root of all that too (yes that's you too scumbag) https://yro.slashdot.org/comme...

APK

P.S.=> CodeSigning you "praise" (I don't for GOOD REASONS & I use something better) can & HAS been STOLEN & ABUSED https://www.helpnetsecurity.co... MY METHOD CAN'T BE (upmodded +2 INTERESTING in CODING FOR DEFCON no less) https://it.slashdot.org/commen... ... apk

Re:MORE's coming that's cool... apk

[Aphranius]

What the hell is APK? You're not talking about android app packages, right?

Gosh! Much Winning!

[Anonymous Coward]

Trumpet a minor tech change that hardly anyone cares about, with negligible impact on users, and proclaim it a big win! This is everything that's wrong with Linux and the Linux culture, in a nutshell.

Just look at the proclaimed benefits of this change:

"1. Using variable-length arrays can add some minor run-time overhead to the code due to needing to determine the size of the array at run-time.
  2. VLAs within structures is not supported by the LLVM Clang compiler and thus an issue for those wanting to build the kernel outside of GCC, Clang only supports the C99-style VLAs.
  3. Arguably most importantly is there can be security implications from VLAs around the kernel's stack usage."

Words like "minor", "an issue" (but only outside of GCC), and "arguably" abound.

It's not that this change shouldn't have been made, and has some benefits. It's about what you choose to focus on. This is the ultimate in inside baseball, a tech issue that only programmers care about. Don't play up this sh*t! This entire announcement should have fallen into a news release phrase that reads like "and numerous technical improvements".

It's also not that Linux and Linux culture is "bad" or "wrong", it's about how it so quickly slips into navel-gazing about obscure internal matters. In the publishing business this is known as "burying the lede" and it is universally understood to be a Bad Thing. So why does Linux keep doing this? Even on /., this stuff is too trivial to matter.

Re:Purely arbitrary/personal BUT... apk

[Anonymous Coward]

Just so everyone knows Dr. Angelo is what Alexander Peter Kowalski has named the jar of mayonnaise he keeps forgetting to put in the refrigerator. His posts, like the one above, are a clear sign of his continuing untreated debilitating mental illness.

Choose one, or BOTH

[Anonymous Coward]

You also LIED trying to "take credit" for a SOLUTION to C++ string buffer overflow issues I SOLVED WAY BEFORE YOU https://tech.slashdot.org/comm... [slashdot.org] proof's right there scumbag punk you are.

You dumbass, that was in CUJ some 20 years ago. You didn't invent it. You're either a liar or a fool. Which is it?

ZIP