Jekyll2026-08-22T21:57:28+00:00https://jorenar.com/feed.xmlJorenarJorenarMy art supplies2026-08-22T00:00:00+00:002026-08-22T00:00:00+00:00https://jorenar.com/my-art-suppliesMechanical pencils
]]>JorenarRetrieving array length across languages2024-12-26T00:00:00+00:002024-12-26T00:00:00+00:00https://jorenar.com/arrlen-across-langs
.langs-list {
column-count: 3;
}
@media only screen and (max-width: 700px) {
.langs-list {
column-count: 2;
}
}
@media only screen and (max-width: 500px) {
.langs-list {
column-count: 1;
}
}
The upcoming revision of the C language standard (for now called C2y) is
about to feature a new operator that essentially is a standardization of
ages old sizeof arr / sizeof arr[0] trick for getting number of elements
in an array. But as we all know, beside cache invalidation, and off-by-one
errors, the 2nd hard problem in Computer Science is naming things.
Initially it was supposed to be just a quick e-mail during the discussion
with just few examples, but as I've gone into the rabbit hole, it somehow
ended in a white paper format. You can read that version on the WG14 website
as document N3402.
I'm fairly sure over 100 languages listed in the "official" document is good
enough sample size of a prior art to decide upon good name for C language,
thus to not spam the committee further, any updates and additions I'll list
here, in this blogpost copy of the paper.
Some of the listed languages provide multiple ways of retrieving number
of elements. Sometimes the ways are equivalent, but usually the underlying
mechanism is different.
e.g. Ruby has .length, but .count without condition also gives
the number of elements;
e.g. C++ allows calculating array length via sizeof arr / sizeof arr[0],
by using std::size() function, by passing the type to std::extent_v<T>
trait template, and couple other ways.
If such additional method was not a primary or prominent way,
or at least from the focus group, it might be missing from the list.
The vast majority of languages use derivatives of either "length" or "size",
with "length" being the dominat base.
"Length" and "size" are also often used for other linear data structures
beside arrays, like strings, linked lists, queues, etc.
Documentations, specifications and communities use terms "length" and "size"
quite freely and interchangeably in the meaning of "the number of elements
in data structure". Sometimes languages make them alias one another.
Other words also sometimes are seen as synonyms, although rarely and/or in
specific contexts (e.g. "dimension" or "extent" would primarily be present
when generalizing to multi-dimensional arrays).
"Count" is 3rd most popular choice, albeit significantly lesser number of
languages represent this category. Sometimes it is a side effect of more
versatile feature (e.g. in meaning "count of X in Y", where Y might contain
more than just Xs).
4th most common word is "dimension"; 5th are ex aequo "elements" and "cardinality".
Including methods of calculating number of elements puts "bounds" in top 5 too.
##
]]>JorenarGeneration 2½ of video game consoles2023-11-01T00:00:00+00:002023-11-01T00:00:00+00:00https://jorenar.com/two-half-console-genInitially I wanted to write a full fledged text about the topic, but then I've found
a decade old article Why the Second Generation of Video Game Consoles Is Really Two
Distinct and Separate Generations by Rev. Robert A. Vinciguerra
on the archive of their blog The Rev. Rob Times, which more or
less encapsulates what I've planned to say...
Therefore, I'm limiting myself to short note with few links:
]]>JorenarCreating rootfs.tar.gz from Linux LiveCD2023-10-05T00:00:00+00:002023-10-05T00:00:00+00:00https://jorenar.com/livecd-2-rootfs-tar-gzWhile the user facing part of LiveCD works mostly the same across Linux distros,
the internals can be more or less different. That's why in this text I'll present
how to extract filesystem from two distributions: Debian and Fedora. That ought
to give anyone enough overview to reproduce for any other distribution.
TL;DR
Debian
sudo mkdir /mnt/iso
sudo mount -o loop debian-live-12.1.0-amd64-standard.iso /mnt/iso
cd /mnt/iso
sudo unsquashfs -d /tmp/squashfs ./live/filesystem.squashfs
cd /tmp/squashfs
sudo tar -vzcp -f ~/rootfs.tar.gz .
sudo chown $USER:$USER ~/rootfs.tar.gz
cd ~
sudo umount /mnt/iso
sudo rmdir /mnt/iso
sudo rm -r /tmp/squashfs
Fedora
sudo mkdir /mnt/iso
sudo mount -o loop Fedora-Workstation-Live-x86_64-38-1.6.iso /mnt/iso
cd /mnt/iso
sudo unsquashfs -d /tmp/squashfs ./LiveOS/squashfs.img
cd /tmp/squashfs
sudo mkdir /mnt/rootfs
sudo mount -o loop LiveOS/rootfs.img /mnt/rootfs
cd /mnt/rootfs
sudo tar -vzcp -f ~/rootfs.tar.gz .
sudo chown $USER:$USER ~/rootfs.tar.gz
cd ~
sudo umount /mnt/iso
sudo umount /mnt/rootfs
sudo rmdir /mnt/iso /mnt/rootfs
sudo rm -r /tmp/squashfs
Prerequisites
Linux environment (probably any other *nix will also do)
As we seen in previous step, for Debian we already dug out
its filesystem, but there's only rootfs.img file for Fedora.
We can mount it as we did with ISOs to reach its content.
]]>JorenarGOTOphobia considered harmful2023-02-26T00:00:00+00:002023-02-26T00:00:00+00:00https://jorenar.com/gotophobia-harmful
gotophobia -- fear of goto statement; usually caused by a lack of context,
and misunderstanding of stories from dark ages of programming. Programmers with
gotophobia tend to make their code less readable just to avoid using goto.
Everybody and their grandpa knows (the meme-ish title of) Dijkstra's
Letters to the editor: go to statement considered harmful
(submitted under the title: A case against the goto statement),
but most forget the context of the 60s in which it was written,
things we take for granted were a novelty back then.
A lot of programmers learnt the craft in a world where goto was the main method
of flow control; even in structured languages it was easy for them to fall back
on the bad habits and techniques.
On the other hand, today we have the very opposite situation: programmers not
using goto when it's appropriate and abusing other constructs, what ironically
makes code only less readable. They overfocus on the WHAT ("remove goto")
rather than the WHY ("because it improves readability and maintainability").
Academic teachers parroting "goto evil" while not really understanding the
language they teach only worsens the matter [speaking from experience]. Because
who needs to learn good practices and discipline, right? It's obviously better
to just ignore the topic entirely and let the students later wonder why they get
attacked by velociraptors.
A "goto" is not, in and of itself, dangerous -- it is a language feature,
one that directly translates to the jump instructions implemented in machine
code. Like pointers, operator overloading, and a host of other "perceived"
evils in programming, "goto" is widely hated by those who've been bitten by
poor programming. [redacted poorly expressed take]
If you think people can't write spaghetti code in a "goto-less" language, I
can send you some lovely examples to disabuse you of that notion. ;)
Used over short distances with well-documented labels, a "goto" can be more
effective, faster, and cleaner than a series of complex flags or other
constructs. The "goto" may also be safer and more intuitive than the
alternative. A "break" is a goto; a "continue" is a "goto" -- these are
statements that move the point of execution explicitly.
Linux kernel is one thing, but if even such restrictive coding standard
as MISRA C (2012 edition) can downgrade the prohibition on goto from
required to advisory, I think in regular code we can safely use goto
in judicious manner.
Thus, I want to present some situations and patterns where goto could be
acceptable (perhaps the best?) choice and you could maybe want to consider
using it. I'll also try to mention goto-less alternatives and their potential
drawbacks (you presumably already are familiar with their advantages as well
as with the possible hitches of goto versions).
Resources
The C Programming Language, 2nd ed. by Kernighan & Ritchie
Poster child of using goto -- most of the time accepted, often recommended,
sometimes even straight up mandated. This idiom results in a good quality code,
because the operations of the algorithm are structured in a clear order,
while errors and other overhead is handled somewhere else, outside the mainline.
The alternatives make the code less readable as it's hard to spot where the
main code is buried among the error checks.
From SEI CERT C Coding Standard:
Many functions require the allocation of multiple resources. Failing and
returning somewhere in the middle of this function without freeing all of
the allocated resources could produce a memory leak. It is a common error
to forget to free one (or all) of the resources in this manner, so a goto
chain is the simplest and cleanest way to organize exits while preserving
the order of freed resources.
int *foo(int bar)
{
int *return_value = NULL;
if (!do_something(bar)) {
goto error_didnt_sth;
}
if (!init_stuff(bar)) {
goto error_bad_init;
}
if (!prepare_stuff(bar)) {
goto error_bad_prep;
}
return_value = do_the_thing(bar);
error_bad_prep:
clean_stuff();
error_bad_init:
destroy_stuff();
error_didnt_sth:
undo_something();
return return_value;
}
int *foo(int bar)
{
int *return_value = NULL;
if (!do_something(bar)) {
undo_something();
return return_value;
}
if (!init_stuff(bar)) {
destroy_stuff();
undo_something();
return return_value;
}
if (!prepare_stuff(bar)) {
clean_stuff();
destroy_stuff();
undo_something();
return return_value;
}
clean_stuff();
destroy_stuff();
undo_something();
return do_the_thing(bar);
}
Example from Linux kernel rewritten
static int mmp2_audio_clk_probe(struct platform_device *pdev)
{
// ...
pm_runtime_enable(&pdev->dev);
ret = pm_clk_create(&pdev->dev);
if (ret) {
pm_runtime_disable(&pdev->dev);
return ret;
}
ret = pm_clk_add(&pdev->dev, "audio");
if (ret) {
pm_clk_destroy(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return ret;
}
ret = register_clocks(priv, &pdev->dev);
if (ret) {
pm_clk_destroy(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return ret;
}
return 0;
}
goto-less alternative 3: flags
Drawbacks:
additional variables
"cascading" booleans
potential nesting
potential complicated boolean expressions
int *foo(int bar)
{
int *return_value = NULL;
bool flag_1 = false;
bool flag_2 = false;
bool flag_3 = false;
flag_1 = do_something(bar);
if (flag_1) {
flag_2 = init_stuff(bar);
}
if (flag_2) {
flag_3 = prepare_stuff(bar);
}
if (flag_3) {
return_value = do_the_thing(bar);
}
if (flag_3) {
clean_stuff();
}
if (flag_2) {
destroy_stuff();
}
if (flag_1) {
undo_something();
}
return return_value;
}
goto-less alternative 3.5: so-far-ok flag
int foo(int bar)
{
int return_value = 0;
bool something_done = false;
bool stuff_inited = false;
bool stuff_prepared = false;
bool oksofar = true;
if (oksofar) { // this IF is optional (always execs) but included for consistency
if (do_something(bar)) {
something_done = true;
} else {
oksofar = false;
}
}
if (oksofar) {
if (init_stuff(bar)) {
stuff_inited = true;
} else {
oksofar = false;
}
}
if (oksofar) {
if (prepare_stuff(bar)) {
stuff_prepared = true;
} else {
oksofar = false;
}
}
// Do the thing
if (oksofar) {
return_value = do_the_thing(bar);
}
// Clean up
if (stuff_prepared) {
clean_stuff();
}
if (stuff_inited) {
destroy_stuff();
}
if (something_done) {
undo_something();
}
return return_value;
}
Example from Linux kernel rewritten
static int mmp2_audio_clk_probe(struct platform_device *pdev)
{
// ...
pm_runtime_enable(&pdev->dev);
bool destroy_pm_clk = false;
ret = pm_clk_create(&pdev->dev);
if (!ret) {
ret = pm_clk_add(&pdev->dev, "audio");
if (ret) {
destroy_pm_clk = true;
}
}
if (!ret) {
ret = register_clocks(priv, &pdev->dev);
if (ret) {
destroy_pm_clk = true;
}
}
if (ret) {
if (destroy_pm_clk) {
pm_clk_destroy(&pdev->dev);
}
pm_runtime_disable(&pdev->dev);
return ret;
}
return 0;
}
Example from Linux kernel rewritten
static int mmp2_audio_clk_probe(struct platform_device *pdev)
{
// ...
pm_runtime_enable(&pdev->dev);
bool destroy_pm_clk = false;
bool disable_pm_runtime = false;
ret = pm_clk_create(&pdev->dev);
if (ret) {
disable_pm_runtime = true;
}
if (!ret) {
ret = pm_clk_add(&pdev->dev, "audio");
if (ret) {
destroy_pm_clk = true;
}
}
if (!ret) {
ret = register_clocks(priv, &pdev->dev);
if (ret) {
destroy_pm_clk = true;
}
}
if (destroy_pm_clk) {
pm_clk_destroy(&pdev->dev);
}
if (disable_pm_runtime) {
pm_runtime_disable(&pdev->dev);
}
return ret;
}
goto-less alternative 4: functions
Drawbacks:
More objects (not only new functions, but often also structs)
"Entia non sunt multiplicanda praeter necessitatem"
deeper callstack
often require passing context around
increase in pointing to pointers
aforementioned additional structs
fragmented code
temptation to needlessly abstract it away
static inline int foo_2(int bar)
{
int return_value = 0;
if (prepare_stuff(bar)) {
return_value = do_the_thing(bar);
}
clean_stuff();
return return_value;
}
static inline int foo_1(int bar)
{
int return_value = 0;
if (init_stuff(bar)) {
return_value = foo_2(bar);
}
destroy_stuff();
return return_value;
}
int foo(int bar)
{
int return_value = 0;
if (do_something(bar)) {
return_value = foo_1(bar);
}
undo_something();
return return_value;
}
Example from Linux kernel rewritten
static inline int mmp2_audio_clk_probe_3(struct platform_device* pdev)
{
int ret = register_clocks(priv, &pdev->dev);
if (ret) {
pm_clk_destroy(&pdev->dev);
}
return ret;
}
static inline int mmp2_audio_clk_probe_2(struct platform_device* pdev)
{
int ret = pm_clk_add(&pdev->dev, "audio");
if (ret) {
pm_clk_destroy(&pdev->dev);
} else {
ret = mmp2_audio_clk_probe_3(pdev);
}
return ret;
}
static inline int mmp2_audio_clk_probe_1(struct platform_device* pdev)
{
int ret = pm_clk_create(&pdev->dev);
if (ret) {
pm_runtime_disable(&pdev->dev);
} else {
ret = mmp2_audio_clk_probe_2(pdev);
if (ret) {
pm_runtime_disable(&pdev->dev);
}
}
return ret;
}
static int mmp2_audio_clk_probe(struct platform_device* pdev)
{
// ...
pm_runtime_enable(&pdev->dev);
ret = mmp2_audio_clk_probe_1(pdev);
return ret;
}
goto-less alternative 5: abuse of loops
Drawbacks:
half of the drawback of goto
half of the drawback of other alternatives
none of the benefits of either of the above
not structural anyway
creates loop which doesn't loop
abuse of one language construct just to avoid using the right tool for the job
less readable
counter intuitive, confusing
adds unnecessary nesting
takes more lines
don't even think about using a legitimate loop somewhere among this mess
useless when we wrap it around actual loop or switch statement
("breaking on error" will stop only that one loop/switch instead of whole thing)
int *foo(int bar)
{
int *return_value = NULL;
do {
if (!do_something(bar)) break;
do {
if (!init_stuff(bar)) break;
do {
if (!prepare_stuff(bar)) break;
return_value = do_the_thing(bar);
} while (0);
clean_stuff();
} while (0);
destroy_stuff();
} while (0);
undo_something();
return return_value;
}
Example from Linux kernel rewritten
static int mmp2_audio_clk_probe(struct platform_device *pdev)
{
// ...
pm_runtime_enable(&pdev->dev);
do {
ret = pm_clk_create(&pdev->dev);
if (ret) break;
do {
ret = pm_clk_add(&pdev->dev, "audio");
if (ret) break;
ret = register_clocks(priv, &pdev->dev);
if (ret) break;
} while (0);
pm_clk_destroy(&pdev->dev);
} while (0);
pm_runtime_disable(&pdev->dev);
return ret;
}
Restart/retry
Common especially on *nix systems when dealing with system calls returning
an error after being interrupted by a signal + setting errno to EINTR
to indicate the it was doing fine and was just interrupted.
Of course, it's not limited to system calls.
#include <errno.h>
int main()
{
RETRY_SYSCALL:
if (some_syscall() == -1) {
if (errno == EINTR) {
goto RETRY_SYSCALL;
}
// handle real errors
}
return 0;
}
goto-less alternative: loop
We can of course use a do {} while loop with conditions in while:
#include <errno.h>
int main()
{
int res;
do {
res = some_system_call();
} while (res == -1 && errno == EINTR);
if (res == -1) {
// handle real errors
}
return 0;
}
I think both versions are comparatively readable, but goto has slight advantage
by making it immediately clear the looping is not a desirable situation, while
while loop may be misinterpreted as waiting loop.
Less trivial example
For those, I'm willing to break the overall monochrome theme of the site and
define colors for syntax highlights. Even with simple parsing done by kramdown
(your code editor would certainty do a better job here), we already notice
labels and goto statements standing out a little from the rest of the code.
Flags on the other hand get lost among other variables.
goto version
#include<string.h>enum{PKT_THIS_OPERATION,PKT_THAT_OPERATION,PKT_PROCESS_CONDITIONALLY,PKT_CONDITION_SKIPPED,PKT_ERROR,READY_TO_SEND,NOT_READY_TO_SEND};intparse_packet(){staticintpacket_error_count=0;intpacket[16]={0};intpacket_length=123;_Boolpacket_condition=1;intpacket_status=4;// get packet etc. ...REPARSE_PACKET:switch(packet[0]){casePKT_THIS_OPERATION:if(/* problem condition */){gotoPACKET_ERROR;}// ... handle THIS_OPERATIONbreak;casePKT_THAT_OPERATION:if(/* problem condition */){gotoPACKET_ERROR;}// ... handle THAT_OPERATIONbreak;// ...casePKT_PROCESS_CONDITIONALLY:if(packet_length<9){gotoPACKET_ERROR;}if(packet_condition&&packet[4]){packet_length-=5;memmove(packet,packet+5,packet_length);gotoREPARSE_PACKET;}else{packet[0]=PKT_CONDITION_SKIPPED;packet[4]=packet_length;packet_length=5;packet_status=READY_TO_SEND;}break;// ...default:PACKET_ERROR:packet_error_count++;packet_length=4;packet[0]=PKT_ERROR;packet_status=READY_TO_SEND;break;}// ...return0;}
goto-less version
#include<string.h>enum{PKT_THIS_OPERATION,PKT_THAT_OPERATION,PKT_PROCESS_CONDITIONALLY,PKT_CONDITION_SKIPPED,PKT_ERROR,READY_TO_SEND,NOT_READY_TO_SEND};intparse_packet(){staticintpacket_error_count=0;intpacket[16]={0};intpacket_length=123;_Boolpacket_condition=1;intpacket_status=4;// get packet etc. ..._BoolREPARSE_PACKET=true;_BoolPACKET_ERROR=false;while(REPARSE_PACKET){REPARSE_PACKET=false;PACKET_ERROR=false;switch(packet[0]){casePKT_THIS_OPERATION:if(/* problem condition */){PACKET_ERROR=true;break;}// ... handle THIS_OPERATIONbreak;casePKT_THAT_OPERATION:if(/* problem condition */){PACKET_ERROR=true;break;}// ... handle THAT_OPERATIONbreak;// ...casePKT_PROCESS_CONDITIONALLY:if(packet_length<9){PACKET_ERROR=true;break;}if(packet_condition&&packet[4]){packet_length-=5;memmove(packet,packet+5,packet_length);REPARSE_PACKET=true;break;}else{packet[0]=PKT_CONDITION_SKIPPED;packet[4]=packet_length;packet_length=5;packet_status=READY_TO_SEND;}break;// ...default:PACKET_ERROR=true;break;}if(PACKET_ERROR){packet_error_count++;packet_length=4;packet[0]=PKT_ERROR;packet_status=NOT_READY_TO_SEND;break;}}// ...return0;}
Common code in switch statement
This situation may be a good opportunity to check if the code doesn't need to
be refactored altogether; that being said, sometimes you want to have switch
statement where cases make minor changes then run the same code.
Sure, you could extract the common code into function, but then you need to pass
all the context to it, but that may be inconvenient (for you may need to pass
a lot of parameters or making a dedicated structure, in both cases probably with
pointers) and may increase complexity of the code; in some cases, you may wish
there being only one call to the function instead of multiple.
So why not just jump to the common code?
int foo(int v)
{
// ...
int something = 0;
switch (v) {
case FIRST_CASE:
something = 2;
goto common1;
case SECOND_CASE:
something = 7;
goto common1;
case THIRD_CASE:
something = 9;
goto common1;
common1:
/* code common to FIRST, SECOND and THIRD cases */
break;
case FOURTH_CASE:
something = 10;
goto common2;
case FIFTH_CASE:
something = 42;
goto common2;
common2:
/* code common to FOURTH and FIFTH cases */
break;
}
// ...
}
goto-less alternative 1: functions
Drawbacks:
"Entia non sunt multiplicanda praeter necessitatem"
reading bottom-up instead of top-bottom
may require passing context around
struct foo_context {
int *something;
// ...
};
static void common1(struct foo_context ctx)
{
/* code common to FIRST, SECOND and THIRD cases */
}
static void common2(struct foo_context ctx)
{
/* code common to FOURTH and FIFTH cases */
}
int foo(int v)
{
struct foo_context ctx = { NULL };
// ...
int something = 0;
ctx.something = &something;
switch (v) {
case FIRST_CASE:
something = 2;
common1(ctx);
break;
case SECOND_CASE:
something = 7;
common1(ctx);
break;
case THIRD_CASE:
something = 9;
common1(ctx);
break;
case FOURTH_CASE:
something = 10;
common2(ctx);
break;
case FIFTH_CASE:
something = 42;
common2(ctx);
break;
}
// ...
}
goto-less alternative 2: ifs
We can abandon elegance and replace the switch statement with ifs
int foo(int v)
{
// ...
int something = 0;
if (v == FIRST_CASE || v == SECOND_CASE || v == THIRD_CASE) {
if (v == FIRST_CASE) {
something = 2;
} else if (v == SECOND_CASE) {
something = 7;
} else if (v == THIRD_CASE) { // it could be just `else`
something = 9;
}
/* code common to FIRST, SECOND and THIRD cases */
} else if (v == FOURTH_CASE || v == FIFTH_CASE) {
if (v == FOURTH_CASE) {
something = 10;
} else {
something = 42;
}
/* code common to FOURTH and FIFTH cases */
}
// ...
}
goto-less alternative 3: interlacing if (0)
Do... do I really need to comment?
You cannot say "interlacing good" while at the same time claiming "goto bad"!
int foo(int v)
{
// ...
int something = 0;
switch (v) {
case FIRST_CASE:
something = 2;
if (0) {
case SECOND_CASE:
something = 7;
}
if (0) {
case THIRD_CASE:
something = 9;
}
/* code common to FIRST, SECOND and THIRD cases */
break;
case FOURTH_CASE:
something = 10;
if (0) {
case FIFTH_CASE:
something = 42;
}
/* code common to FOURTH and FIFTH cases */
break;
}
// ...
}
goto-less alternative: capturing lambda
Yeah, maybe some day...
Nested break, labeled continue
I think this one doesn't require further explanation:
#include <stdio.h>
int main()
{
for (int i = 1; i <= 5; ++i) {
printf("outer iteration (i): %d\n", i);
for (int j = 1; j <= 200; ++j) {
printf(" inner iteration (j): %d\n", j);
if (j >= 3) {
break; // breaks from inner loop, outer loop continues
}
if (i >= 2) {
goto outer; // breaks from outer loop, and directly to "Done!"
}
}
}
outer:
puts("Done!");
return 0;
}
The following is a 1:1, not far from verbatim mathematical notation,
implementation of the above automata:
_Bool machine(const char *c)
{
qA:
switch (*(c++)) {
case 'x': goto qB;
case 'y': goto qC;
case 'z': goto qA;
default: goto err;
}
qB:
switch (*(c++)) {
case 'x': goto qB;
case 'y': goto qA;
case '\0': goto F;
default: goto err;
}
qC:
switch (*(c++)) {
case 'x': goto qC;
case 'z': goto qB;
default: goto err;
}
F:
return true;
err:
return false;
}
Jumping into event loop
Yeah, yeah, I know jumping into warrants at least a raised eyebrow.
That being said, there are cases when you may want to do just that.
Here in first iteration program skips increasing variable and goes straight
to allocation. Each following iteration executes code as written, ignoring
completely the label relevant only for the first run; so you do too during
analysis.
#include <stdio.h>
#include <fancy_alloc.h>
int main()
{
int *buf = NULL;
size_t pos = 0;
size_t sz = 8;
int *temp;
goto ALLOC;
do {
if (pos > sz) { // resize array
sz *= 2;
ALLOC: temp = arrayAllocSmart(buf, sz, pos);
/* check for errors */
buf = temp;
}
/* do something with buf */
} while (checkQuit());
return 0;
/* handle errors ... */
}
goto-less alternative 1: guard flag
It probably says more about the state of my sleep deprived brain than anything
else, but I actually managed to make an honest, very dumb mistake in this
simple snippet. I didn't notice until after examining the assembly output
and seeing way less instructions than expected. Since it's simple, yet quite
severe in consequences, I decided to leave it as an exercise for the reader
to spot the bug (should be easy since you already know about its existence).
The drawbacks as per usual: nesting and keeping track of flags.
#include <stdio.h>
#include <fancy_alloc.h>
int main()
{
int *buf = NULL;
size_t pos = 0;
size_t sz = 8;
int ret = 0
_Bool firstIter = true;
do {
if (pos > sz || firstIter) { // resize array
if (!firstIter) {
sz *= 2;
firstIter = false;
}
int *temp = arrayAllocSmart(buf, sz, pos);
/* handle errors ... */
buf = temp;
}
/* do something with buf */
} while (checkQuit());
return 0;
}
goto-less alternative 2: code duplication
The drawback is obvious, thus no further comment.
#include <stdio.h>
#include <fancy_alloc.h>
int main()
{
size_t pos = 0;
size_t sz = 8;
int *buf = arrayAllocSmart(NULL, sz, pos);
/* handle errors ... */
do {
if (pos > sz) { // resize array
sz *= 2;
int *temp = arrayAllocSmart(buf, sz, pos);
/* handle errors ... */
buf = temp;
}
/* do something with buf */
} while (checkQuit());
return 0;
}
Optimizations
This section is purely informative, just to appear on list as to mark the
existence of such use-case. Giving an example for this is not so easy, either
from legal or conceptual standpoint as most of them apply only in very narrow
situations, not rarely bordering on micro-optimizing.
Beej shows tail call optimization
as an example in his book. Unfortunately (from educational standpoint! otherwise, it's a great thing)
modern compilers easily optimize something as simple as factorial to the very same assembly which we get
using the goto optimization. On the other hand, not everybody is blessed with modern, optimizing compiler...
If I started from Dijkstra, it's only natural I need to conclude with Knuth.
Almost anybody who says anything positive about goto refers to this paper.
And rightfully so! To this day it's one of most comprehensive resources
on the topic (it's a go to resource about goto). Perhaps some examples
are quite dated, some concerns less crucial today than back in the day,
but nevertheless it's an excellent read.
One thing we haven't spelled out clearly, however, is what makes some
go to's bad and others acceptable. The reason is that we've really
been directing our attention to the wrong issue, to the objective question of
go to elimination instead of the important subjective question of
program structure. In the words of John Brown, "The act of focusing our
mightiest intellectual resources on the elusive goal of go to-less
programs has helped us get our minds off all those really tough and possibly
unresolvable problems and issues with which today's professional programmer
would otherwise have to grapple." By writing this long article I don't want
to add fuel to the controversy about go to elimination, since that topic
has already assumed entirely too much significance; my goal is to lay that
controversy to rest, and to help direct the discussion towards more fruitful
channels.
]]>JorenarShort list of C esoterica2023-02-19T00:00:00+00:002023-02-19T00:00:00+00:00https://jorenar.com/c-esotericaThere are some tricks, quirks, and features which seems to throw even
experienced developers off the track. Thus, I periodically revisit this
blogpost, to do a sloppy job of gathering them in an unordered list with
some short explanations, examples, quotes, or references.
Obviously though, I'm not gonna list absolutely everything, for facts like
"function nan() cannot set errno as it shall behave like strtod() in
certain cases" ain't so much fun.
Names of variables can be wrapped in parentheses in declarations:
int (v);
void (*p);
float (ar1)[16];
double (ar1[8]);
int x, (*y), (z);
Array pointers
Decay-to-pointer makes regular pointers to array usually not needed:
int arr[10];
int *ap0 = arr; // array decay-to-pointer
// ap0[2] = ...
int (*ap1)[10] = &arr; // proper pointer to array
// (*ap1)[2] = ...
But ability to allocate a big multi-dimensional array on heap is nice:
int (*ap3)[90000][90000] = malloc(sizeof *ap3);
With pointers even VLA can find its use (more here):
int (*ap4)[n] = malloc(sizeof *ap4);
Comma operator
The comma operator is used to separate two or more expressions that are
included where only one expression is expected. When the set of expressions
has to be evaluated for a value, only the right-most expression is considered.
For example: b = (a=3, a+2); -- this code would firstly assign value 3
to a, and then a+2 would be assigned to variable b. So, at the end,
b would contain value 5 while variable a would be 3.
C code may not be portable, but the language itself is probably more portable
than any other; there are system using e.g. EBCDIC encoding instead of ASCII,
to support them C has digraphs and trigraphs -- multi-character sequences
treated by the compiler as other characters.
These allow you to specify which elements of an object (array, structure, union)
are to be initialized by the values following. The order does not matter!
A compound literal looks like a cast of a brace-enclosed initializer list.
Its value is an object of the type specified in the cast, containing the
elements specified in the initializer.
Even if you already knew about compound literals, there's a high chance you've
never consciously noticed them being lvalues. And it's important, because when
a value is an lvalue, we can get its address (and e.g. pass it to function).
Escaping shadowing
The following code will return 42, not 3840!
int x = 42;
int func() {
int x = 3840;
{
extern int x;
return x;
}
}
Multi-character constants
They are implementation dependent and even the standard itself to usually
best avoid them. That being said, using them as self-documenting enums
can be quite handy when you may need to deal with raw memory dumps later on.
A zero-length bit-field can be used to make the following changes:
Creates a boundary between any bit-fields before the zero-length bit-field
and any bit-fields after the zero-length bit-field. Any bit-fields on
opposite sides of the boundary are treated as non-overlapping memory
locations. This has a consequence for C and C++ programs. The C and C++
standards require both load and store accesses to a bit-field on one side
of the boundary to not access any bit-fields on the other side of the boundary.
Insert padding to align any bit-fields after the zero-length bit-field to
the next available natural boundary based on the type of the zero-length
bit-field. For example, char:0 can be used to align to the next available
byte boundary, and int:0 can be used to align to the next available word boundary.
An example taken from the SO answer (with slight changes):
struct bar {
unsigned char x : 5;
unsigned short : 0;
unsigned char y : 7;
}
The above in memory would look like this (assuming 16-bit short, ignoring endian):
char pad pad short boundary
| | | |
v v v v
xxxxx000 00000000 yyyyyyy0
The zero-length bit field causes the position to move to next short boundary
(or: be placed on the nearest natural alignment for the target platform).
We defined short to be 16-bit, so 16 minus 5 gives 11 bits of padding.
volatile type qualifier
This qualifier tells the compiler that a variable may be accessed by other
means than the current code (e.g. we are dealing with MMIO device), thus to
not optimize away reads and writes to this resource.
By adding this type qualifier, a programmer hints to the compiler that for
the lifetime of the pointer, no other pointer will be used to access the object
to which it points. This allows the compiler to make optimizations (for example,
vectorization) that would not otherwise have been possible.
It suggests that the compiler stores a declared variable in a CPU register
(or some other faster location) instead of in random-access memory.
The location of a variable declared with this qualifier cannot be accessed
(but the sizeof operator can be applied).
Nowadays register is usually meaningless as modern compilers place variables
in a register if appropriate regardless of whether the hint is given. Sometimes
may it be useful on embedded systems, but even then compiler will probably
provide better optimizations.
Flexible array member
From Wikipedia:
struct vectord {
short len; // there must be at least one other data member
double arr[]; // the flexible array member must be last
// The compiler may reserve extra padding space here,
// like it can between struct members.
};
struct vectord *vector = malloc(...);
vector->len = ...;
for (int i = 0; i < vector->len; ++i) {
vector->arr[i] = ...; // transparently uses the right type (double)
}
%n returns the current position of the imaginary cursor used when printf() formats its output.
int pos1, pos2;
const char *str_of_unknown_len = "we don't care about the length of this";
printf("Write text of unknown %n(%s)%n length\n", &pos1, str_of_unknown_len, &pos2);
printf("%*s\\%*s/\n", pos1, " ", pos2-pos1-2, " ");
printf("%*s", pos1+1, " ");
for (int i = pos1+1; i < pos2-1; ++i) {
putc('-', stdout);
}
putc('\n', stdout);
will have following output
Write text of unknown (we don't care about the length of this) length
\ /
--------------------------------------
Granted a little bit contrived but can have some uses when making pretty reports.
when you want to pad with variable number of characters.
Other less known format specifiers
Have a look at §7.21.6.1
and §7.21.6.2
of the draft of C11 standard. You'll find %#, %e, %-, %+, %j, %g, %a and few other interesting specifiers.
Interlacing syntactic constructs
The following is syntactically correct C code:
#include <stdio.h>
int main()
{
int n = 3;
int i = 0;
switch (n % 2) {
case 0:
do {
++i;
case 1:
++i;
} while (--n > 0);
}
printf("%d\n", i); // 5
}
I know gotophobic programmers using it like this:
switch (x) {
case 1:
// 1 specific code
if (0) {
case 2:
// 2 specific code
}
// common for 1 and 2
}
The most famous usage of this quirk/"feature" is Duff's device:
send(to, from, count)
register short *to, *from;
register count;
{
register n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}
--> "operator"
The following is correct C code:
size_t n = 10;
while (n --> 0) {
printf("%d\n", n);
}
You may ask, since when C has such operator and the answer is: since never.
--> is not an operator, but two separate operators -- and > written
in a way they look like one. It's possible, because C cares less than more
about whitespace.
n --> 0 is equivalent of (n--) > 0
idx[arr]
Square brace notation of accessing array elements is a syntactic sugar for pointer arithmetic:
arr[5] ≡ *(arr + 5) ≡ *(5 + arr) ≡ 5[arr]
You absolutely must never use this in actual code... but it's hella fun otherwise!
For quick and dirty debugging purposes I wanted to check if padding at the end
of an array is filled with correct value, but I didn't know where the padding
starts. Thus, I did the following:
int *end = arr + (len - 1);
if (end[0] == VAL && end[-1] == VAL && end[-5] == VAL) {
puts("Correct padding");
}
Constant string concatenation
You don't need sprintf() (nor strcat()!) to concatenate strings literals:
#define WORLD "World!"
const char *s = "Hello " WORLD "\n"
"It's a lovely day, "
"innit?";
Backslash line splicing
Each instance of a backslash character \ immediately followed by a new-line
character is deleted, splicing physical source lines to form logical source lines.
#define I_AM_O\
NE_MACRO 123
// I am a comment. \
I'm stil the same comment. \
I'm a so-called ONE-LINE comment!
int fun()
{
if (drive == 2) // drive 2 is C:\
return 1; <-- my firend here is still part of a COMMENT!!
writestuff();
return 0;
}
int main()
{
int x = I_AM_ONE_MACRO; // correctly expands to 123
int same_\
variable = 1;
same_variable = 1;
const char *p = "String with\
so many spaces in the MIDDLE!";
puts(p); // "String with so many spaces in the MIDDLE!"
return 0;
}
Using && and || as conditionals
If you write Shell scripts, you know what I mean.
#include <ctype.h>
#include <stdio.h>
#include <stdbool.h>
int main(void)
{
1 && puts("Hello");
0 && puts("I won't");
1 && puts("World!");
0 && puts("be printed");
1 || puts("I won't be printed either");
0 || puts("But I will!");
true && (9 > 2) && puts("9 is bigger than 2");
isdigit('9') && puts("9 is a digit");
isdigit('n') && puts("n is a digit") || puts("n is NOT a digit!");
isalpha('a') && !puts("I'll be printed") || puts("But me AS WELL!");
return 0;
}
The compiler will probably scream warnings at you
as it's really uncommon to do this in C code.
A pointer to void may be converted to or from a pointer to any object type.
A pointer to any object type may be converted to a pointer to void and back again;
the result shall compare equal to the original pointer.
C11 §6.5.16.1 ¶1:
—
the left operand has atomic, qualified, or unqualified pointer type, and
(considering the type the left operand would have after lvalue conversion)
one operand is a pointer to an object type, and the other is a pointer to
a qualified or unqualified version of void, and the type pointed
to by the left has all the qualifiers of the type pointed to by the right;
void* was added to C89 because of a need for generic pointer
type which can be implicitly cast back and forth.
In fact, explicitly casting void pointers has the following problems:
it is unnecessary, as void* is automatically and safely promoted to any other pointer type;
it adds clutter to the code, casts are not very easy to read (especially if the pointer type is long);
it makes you repeat yourself;
it can hide an error would return type change from void* to something more concrete.
Except in certain contexts, an unsubscripted array name (for example, region
instead of region[4]) represents a pointer whose value is the address of the
first element of the array, provided that the array has previously been declared.
An array type in the parameter list of a function is also converted to the
corresponding pointer type. Information about the size of the argument array
is lost when the array is accessed from within the function body.
To preserve this information, which is useful for optimization, C99 allows you
to declare the index of the argument array using the static keyword. The constant
expression specifies the minimum pointer size that can be used as an assumption
for optimizations. This particular usage of the static keyword is highly prescribed.
The keyword may only appear in the outermost array type derivation and only in
function parameter declarations. If the caller of the function does not abide
by these restrictions, the behavior is undefined.
The following examples show how the feature can be used.
int n;
void foo(int arr[static 10]); // arr points to the first of at least 10 ints
void foo(int arr[const 10]); // arr is a const pointer
void foo(int arr[const]); // const pointer to int
void foo(int arr[static const n]); // arr points to at least n ints (VLA)
void foo(int p[static 1]); is effectively a standard
way to declare that p must be non-null pointer.
Usually we declare new types using the following syntax:
typedef unsigned char byte;
typedef struct {
int x;
int y;
const char *p;
} Record;
But other placements of typedef keyword are possible:
unsigned typedef char byte;
struct {
int x;
int y;
const char *p;
} typedef Record;
And we can still declare multiple types in one go:
struct {
int x;
int y;
const char *p;
} typedef Record, record, *record_ptr;
Function types
Function pointers ought to be well known, but as we know the syntax is
a bit awkward. On the other hand, less people know you can (as with most
objects in C) create a typedef for function type.
This technique is quite simple to come up with: just think how to make templates
in C using #include. Despite seeing it from time to time in the wild (maybe
even more frequently than X-Macros), seems that until very recently it didn't
even have a name.
But now positional arguments don't work anymore, and there may be situations
where you want to support both options. But I recently realized, that you can
make them work by adding a dummy parameter:
typedef struct { int _; int a,b,c,d; } FooParam;
#define foo(...) foo((FooParam){ .a=1, .b=2, .c=3, .d=4, ._=0, __VA_ARGS__})
Suppose that you have a struct with a bunch of fields, and you want to deal
with some of them all together at once under a single name; perhaps you want
to conveniently copy them as a block through struct assignment.
By using unions you can access both a.field2 and a.sub (and a.field2
is the same as a.sub.field2) without any macros.
struct a {
int field1;
union {
struct {
int field2;
int field3;
};
struct {
int field2;
int field3;
} sub;
};
};
Unity builds
Because #include mechanism is essentially a primitive copy-pasting
contents of included file into the current code, C allows us to make
so called unity builds,
where we dump everything into one translation unit.
Applying this technique
sometimes may lead to faster compile times, simplified build process or provide
opportunity for optimizations. Unfortunately, is doesn't scale well at all as
it doesn't mix with parallel and incremental builds.
It also hinders modularization/encapsulation of code.
sscanf() can be used as an ersatz "regex" (not really, only character classes) matcher.
For example, one can write something like this to check if the input consists of letters or underscores:
int len = 0;
char buf[256];
int read_token = sscanf(input, "%255[a-zA-Z_]", buf, &len);
if (read_token) { /* do something */ }
or skip whitespace characters:
int len = 0;
char buf[256];
sscanf(input, "%255[\r\n]%n", buf, &len);
input += len;
Garbage collector
Boehm GC is a library providing garbage collector for C and C++
Cosmopolitan Libc makes C a build-once run-anywhere language, like Java,
except it doesn't need an interpreter or virtual machine. Instead, it
reconfigures stock GCC and Clang to output a POSIX-approved polyglot format
that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS
with the best possible performance and the tiniest footprint imaginable.
Inline assembly
For a high-level language C communicates quite well with low-level world. You
can write Assembly code and link it against program written in C quite easily.
In addition to that, many compilers offer as an extension (listed as common
in Annex J of the C Standard) a feature called inline assembly, typically
introduced to the code by the asm keyword.
Variadic functions are often sources of subtle bugs because theirs arguments
are not type-checked and can have unintuitive promotion/conversion rules.
There's also a problem that variadic function doesn't know how many arguments
have been passed to it, thus the caller needs to do it manually, either via
some sentinel value that marks the end of arguments (e.g execl() using
NULL to mark the end) or by passing the size via another parameter.
With some clever usage of C99's variadic macros, combined with compound
literals, these shortcomings can be worked around.
While the below example only works when all parameters are of the same type,
in cases where different types might be needed, it should be possible to
extend this trick with "tagged union" and some usage of C11's _Generic.
C11 added _Generic to language, but turns out metaprogramming
by inhumanely abusing the preprocessor is possible even in pure C99:
meet Metalang99 library.
I've already mentioned some preprocessor tricks, but there's way more!
In fact, I could easily make such a list out of preprocessor oddities alone.
After all, it is a full fledged language with its own rules, grammar, and
caveats; heck, it's not even strictly exclusive to C - there are madlads
using it in conjunction with e.g. JavaScript.
Luckily for me, hirrolot - the author
of aforementioned Metalang99, has already prepared
awesome-c-preprocessor
list with sane and insane deeds possible to do in C preprocessor.
CCAN
Comprehensive C Archive Network, modeled
after Perl's CPAN (which in turn was modeled
after CTAN) is a repository of
C code snippets. While it's not such a necessity like for Perl, nor
is it officially endorsed or widely used, I think its existence is
interesting enough to warrant a mention.
Function pointers to match arrays in _Generic
Right now _Generic doesn't allow for matching arrays, but document
N3348
by Martin Uecker mentions a trick
to make them match by wrapping the type into a function pointer:
Normally forward declaration is done as following:
struct Foo;
void bar(int n, struct Foo *a)
{
if (n) bar(n-1, a);
}
but we can declare and initialize a pointer in one go too:
struct Foo *g = 0;
void bar(int n, struct Foo *a)
{
if (n) bar(n-1, a);
}
or skip global forward declaration:
void bar(int n, struct Foo *a)
{
if (n) bar(n-1, a);
}
Although, beware: technically in
void bar(int n, struct Foo *a);
void baz(struct Foo *b);
pointers a and b are incompatible.
]]>JorenarLegitimate use-cases of VM types in C2023-02-10T00:00:00+00:002023-02-10T00:00:00+00:00https://jorenar.com/vla-usecasesAn earlier version of my Pitfalls of VLA in C article
contained an example of useful case of VLA, but since there are actually
two of them (and I'd be overjoyed being presented with more), they deserve
a dedicated, if low effort, post of their own. After all, those use-cases
are the only reason why I compile with -Wvla-larger-than=0 rather than
more strict and reliable -Wvla.
Size check when passing to function
"Only" a bit over two decades after the introduction of VLA to C language,
GCC started giving warnings about passing to functions bigger than declared
size of arrays when we actually decide to utilize VLA syntax in parameters.
Dynamically allocating multi-dimensional arrays where the inner dimensions
are not known until runtime is really simplified using VM types.
It isn't even as unsafe as aVLA since there's no arbitrary stack allocation.
int (*arr)[n][m] = malloc(sizeof *arr); // `n` and `m` are variables with dimensions
if (arr) {
// (*arr)[i][j] = ...;
free(arr);
}
The VLA-free alternatives aren't as sexy:
piecemeal allocation
int **arr = malloc(n * (sizeof *arr));
if (arr) {
for (int i = 0; i < n; ++i) {
arr[i] = malloc(m * (sizeof *arr[i]));
}
// arr[i][j] = ...
for (int i = 0; i < n; ++i) {
free(arr[i]);
}
free(arr);
}
1D array with offsets
int *arr = malloc(n * m * (sizeof *arr));
if (arr) {
// arr[i*n + j] = ...
free(arr);
}
big fixed array
int arr[SAFE_SIZE][SAFE_SIZE]; // SAFE_SIZE must be safe for SAFE_SIZE*SAFE_SIZE
// arr[i][j] = ...;
]]>JorenarPitfalls of VLA in C2021-07-05T00:00:00+00:002021-07-05T00:00:00+00:00https://jorenar.com/vla-pitfalls
It generates much more code, and much slower code (and more fragile code),
than just using a fixed key size would have done ~ Linus Torvalds
VLA (variable-length array, an array -- array, not just block of memory
acting like one -- that has size determined during runtime instead of at compile
time) is a feature introduced to C with the revision C99 of the standard.
A very useful feature one may think, and indeed... in some cases...
But since the world we live in is less than ideal, one needs to know well what
are the pitfalls of using VLA in their code before doing so.
If you want to know the few cases when VLA may actually
be useful you can check my other blogpost.
A fair share of the text here will focus on problems caused by automatic VLA,
thus to further reflect on that an abbreviation aVLA will be used when
referring to those cases.
Allocation on stack
Let's address the elephant in the room: the standard doesn't say anything about
it, but in practice aVLA usually are allocated on stack. This is the source of
the most of the problems, the source of discontent among programmers, the reason
why even allowing any VLA into the codebase is usually a code smell.
Let's consider a painfully simple, very favourable to aVLA, example:
#include <stdio.h>
int main(void) {
int n;
scanf("%d", &n);
char arr[n];
printf("%d", arr[0]);
return 0;
}
As we can see, it takes a number from user then makes array of that size. Compile
and try it. Check how big values you can input before getting segfault caused
by stack overflow. In my case, it was around 8 MiB.
How much is that? One raw image? a MP3 or two? few seconds of video? And the program
wasn't doing anything meaningful - what if it wasn't just main()? Maybe a recursive
function? The limit shrinks tremendously.
And you don't have any (portable, standard) way to react after a stack
overflow - the program already crashed, you lost control. So you either need
to make elaborate checks before declaring an array or betting that user won't
input too large values (the outcome of such gamble ought to be obvious).
So the programmer must ensure that aVLA size doesn't exceed some safe maximum,
but in reality, if you know safe maximum, there is rarely any reason for not using
it always.
Worst of it is...
... that segfault is actually one of the best outcomes of improperly handled aVLA.
The worst case is an exploitable vulnerability, where attacker may choose a value
that causes an array to overlap with other allocations, giving them control over
those values as well. A security nightmare.
So how to fix this example?
What if I need to let user define size and creating ridiculously large fixed
array would be too wasteful? It's simple: use malloc()!
In this case I was able to request over 4.5 GiB before segfault. Almost few orders
of magnitude more! But I still got the segfault, right? Well, the difference
is in getting at least some* chance of checking the value returned by malloc()
and thus being able to, for example, inform the user about the error:
I've encountered a counterargument, that as C is often used as a systems/embedded
language, there are situations where using malloc() may not even be possible.
I'm basically going to repeat myself here, but it is really important:
Such device rather is not going to have a lot of stack either. So instead of
allocating dynamically, you (probably) should determine how much you need and
just always use that fixed amount.
When using aVLA on system with small amounts of stack, it's really easy to make
something which seems to work, but which blows your stack if your function gets
called from a deep call stack combined with the large amount of data.
If you always allocate fixed amounts of stack space everywhere, and you test
it, you know you're good. If you dynamically allocate on stack, you have to
test all your code paths with all the largest sizes of allocated space, which
is much harder and much easier to make a mistake. Don't make it even easier to
shoot yourself in the foot for no real advantage.
Creation by accident
Unlike most other dangerous C functionality, aVLA doesn't have the barrier
of being not known. Many newbies learn to use them via trial and error, but
don't learn about the pitfalls.
The following is a simple mistake I observed even experienced developers making
(especially those with C++ background); it will silently create an aVLA when
it's clearly not necessary:
const int n = 10;
int A[n];
Thankfully, any half-decent compiler would notice and optimize aVLA away, but...
what if it doesn't notice? Or what if, for some reason (safety?), the optimizations
were not turned on? But it surely isn't so much worse, right? Well...
Way slower than fixed size
Without compiler optimizations a function with aVLA from previous
example will result in 7 times more Assembly
instructions than its fixed size counterpart
before moving past the array definition (look at the body before jmp .L2).
But it's without optimizations, with them the produced Assembly is exactly the same.
#include <stdio.h>
void bar(int*, int);
void foo(int n) {
#if VLA
int A[n];
#else
int A[1000]; // Let's make it bigger than 10!
// (or there won't be what to examine)
#endif
for (int i = n; i--;) {
scanf("%d", &A[i]);
}
bar(A, n);
}
int main(void) {
foo(10);
return 0;
}
For our educational purposes in this example, -O1 level of optimisation will
work best (as Assembly will be clearer and -O2 won't help aVLA's case here
really much).
When we compile aVLA version, before instructions corresponding to for loop, we get:
push rbp
mov rbp, rsp
push r14
push r13
push r12
push rbx
mov r13d, edi
movsx r12, edi ; here aVLA "starts"...
sal r12, 2 ;
lea rax, [r12+15] ;
and rax, -16 ;
sub rsp, rax ;
mov r14, rsp ; ... and there "ends"
The aVLA-free version on the other hand generates:
push r12
push rbp
push rbx
sub rsp, 4000 ; this is caused by array definition
mov r12d, edi
So not only fixed array spawns less code, but also way simpler code.
Why, aVLA even causes more overhead at the beginning of the function.
It's not so much more in the grand scheme of things, but it still isn't
just a pointer bump.
But are those differences significant enough to care?
Yes, they are.
No initialization
To add more to the issue with inadvertent aVLA, the following isn't allowed:
int n = 10;
int A[n] = { 0 };
Even with optimizations, initialisation isn't allowed for aVLA. So despite
wanting fixed size array and compiler being technically able to provide one,
it won't work (and if it does... it's breaking the specification...).
sizeof not resolved at compile time
int n;
scanf("%d", &n);
int A[5];
int B[n];
sizeof A; // compile-time
sizeof B; // run-time
The above is quite obvious, B isn't fully known until n gets its value,
thus it needs to be resolved at run-time. Nothing to write home about.
On the other hand, the following is no longer so obvious
(source of example):
The operand [of sizeof operator] must be evaluated if its type is a VLA; for example:
int i = 0;
static const int n = 5;
int A[5];
int B[n];
sizeof A[i++]; // operand is not evaluated, `i` is still 0
sizeof B[i++]; // operand is evaluated, `i` is 1
sizeof &B[i++]; // operand is not evaluated, `i` stays 1
Mess for compiler writers
Few months ago I saved a comment
on Reddit listing problems encountered with VLA from compiler writer perspective.
I'll allow myself to cite the listed issues:
A VLA applies to a type, not an actual array. So you can create a typedef
of a VLA type, which "freezes" the value of the expression used, even if
elements of that expression change at the time the VLA type is applied
VLAs can occur inside blocks, and inside loops. This means allocating and
deallocating variable-sized data on the stack, and either screwing up all
the offsets, or needing to do things indirectly via pointers.
You can use goto into and out of blocks with active VLAs, with some things
restricted and some not, but the compiler needs to keep track of the mess.
VLAs can be used with multi-dimensional arrays.
VLAs can be used as pointer targets (so no allocation is done, but it still
needs to keep track of the variable size).
Some compilers allow VLAs inside structure definitions (I really have no idea
how that works, or at what point the VLA size is frozen, so that all instances
have the same VLA(s) sizes.)
A function can have dozens of VLAs active at any one time, with some being
created or destroyed at different times, or conditionally, or in loops.
sizeof needs to be specially implemented for VLAs, and all the necessary
info (for actual VLAs, VLA-types, and hybrid VLA/fixed-size types and
arrays and pointed-to VLAs).
'VLA' is also the term used for multi-dimensional array parameters, where
the dimensions are passed by other parameters.
On Windows, with some compilers (GCC at least), declaring local arrays which
make the stack frame size over 4 KiB, mean calling a special allocator
(__chkstk()), as the stack can only grow a page at a time. When a VLA is
declared, since the compiler doesn't know the size, it needs to call
__chkstk for every such function, even if the size turns out to be small.
And believe me, if you take a stroll around some C forums (or the meeting of
standard committee [sic!]) you will see even more different complaints.
Reduced portability
Due to all previously presented problems, some compiler providers decided to
not fully support C99. The primary example is Microsoft with its MSVC.
The C Standard Committee also noticed the problem and with C11 revision
all instances of VLAs were made optional; C23 partially reverts that decision
mandating VM types (aVLA are still optional; there is even a slight sentiment
towards deprecating them entirely, but removing something from the, nomen omen,
standard is way harder than putting it in).
That means code using a VLA won't necessarily be compiled by a C11 compiler,
so you need, assuming you target for portability, to check whether it is
supported with __STDC_NO_VLA__ macro and make version without (a)VLA as
fallback. Wait... if you need to implement VLA-free version either way then
what's the point of doubling the code and creating VLA in the first place?!
(nitpick) Breaking conventions
This one is more of a nitpick, but still another reason to dislike VLA. There
is a widely used convention of first passing object then its parameters, what
in terms of arrays means:
void foo(int** arr, int n, int m) { /* arr[i][j] = ... */ }
C99 specified that array sizes need to be parsed immediately when encountered
within a function definition's parameter list, what means that when using VLA
you cannot do an equivalent of the above:
void foo(int arr[n][m], int n, int m) { /* arr[i][j] = ... */ } // INVALID!
You need to break up with the convention and write:
void foo(int n, int m, int arr[n][m]) { /* arr[i][j] = ... */ }
Alternatively, you could use the obsolete syntax (obsolescent even in
ANSI C; finally removed in C23), but that would be pointless, as
compilers don't make parameters checks in such case, so any benefits
from using VLA would be lost.
void foo(int[*][*], int, int);
void foo(arr, n, n)
int n;
int m;
int arr[n][m]
{
// arr[i][j] = ...
}
Conclusion
In short, refrain from using VLA and avoid automatic VLA like devil avoids
holy water; if your compiler has it, rather compile with -Wvla flag
or similar (and definitely with -Wvla-larger-than=0 - this allows VM types,
while warning about aVLA).
If you find yourself in one of the situations where VLA (or VM type) is a valid/good
solution, of course, do use them, but keep in mind the limits I've outlined here.
]]>JorenarSteps to learn Vim2021-01-23T00:00:00+00:002021-01-23T00:00:00+00:00https://jorenar.com/vim-learning-steps
Project drawers conflict with split windows, favor splits
Visual clutter saps mental energy
Use plugins sparingly
Navigate by tags and search, not files
If it feels hard, there is probably a better way
You should understand every line in your vimrc
UI "tabs" are probably not what you expect
Don't seek mastery, seek proficiency
]]>JorenarVim with XDG Dirs2020-12-13T00:00:00+00:002020-12-13T00:00:00+00:00https://jorenar.com/vim-xdgXDG Base Directory specification, $XDG_CONFIG_HOME etc. Great thing - configs
separated from user data and cache, no clutter in home directory. Unfortunately,
many programs still don't respect it, including Vim. But what would be our favourite
text editor if we wouldn't be able to reconfigure it!
TL;DR
Into environment/shell config (e.g. in ~/.profile):
if [ -x "$(command -v vim)" ]; then
[ "$(vim --clean -es +'exec "!echo" has("patch-9.1.0327")' +q)" -eq 0 ] && \
export VIMINIT="set nocp | source ${XDG_CONFIG_HOME:-$HOME/.config}/vim/vimrc"
fi
At the top of vimrc:
" XDG Base Directory support
if empty($MYVIMRC) | let $MYVIMRC = expand('<sfile>:p') | endif
if empty($XDG_CACHE_HOME) | let $XDG_CACHE_HOME = $HOME."/.cache" | endif
if empty($XDG_CONFIG_HOME) | let $XDG_CONFIG_HOME = $HOME."/.config" | endif
if empty($XDG_DATA_HOME) | let $XDG_DATA_HOME = $HOME."/.local/share" | endif
if empty($XDG_STATE_HOME) | let $XDG_STATE_HOME = $HOME."/.local/state" | endif
if !has('nvim')
set runtimepath^=$XDG_CONFIG_HOME/vim
set runtimepath+=$XDG_DATA_HOME/vim
set runtimepath+=$XDG_CONFIG_HOME/vim/after
set packpath^=$XDG_DATA_HOME/vim,$XDG_CONFIG_HOME/vim
set packpath+=$XDG_CONFIG_HOME/vim/after,$XDG_DATA_HOME/vim/after
set backupdir=$XDG_STATE_HOME/vim/backup | call mkdir(&backupdir, 'p', 0700)
set directory=$XDG_STATE_HOME/vim/swap | call mkdir(&directory, 'p', 0700)
set viewdir=$XDG_STATE_HOME/vim/view | call mkdir(&viewdir, 'p', 0700)
set undodir=$XDG_STATE_HOME/vim/undo | call mkdir(&undodir, 'p', 0700)
set viminfofile=$XDG_STATE_HOME/vim/viminfo
endif
let g:netrw_home = $XDG_DATA_HOME."/vim"
call mkdir($XDG_DATA_HOME."/vim/spell", 'p', 0700)
call mkdir($XDG_STATE_HOME."/vim", 'p', 0700)
Step-by-step
Relocating vimrc
Since version 7.3.1178, Vim will search for ~/.vim/vimrc if ~/.vimrc
is not found. So let's move the file there.
Let's move our ~/.vim to $XDG_CONFIG_HOME/vim. Now we need to command Vim
to read config from this new location prior to ~/.vim.
If you have Vim 9.1.0327 or newer, you are in luck! From that version Vim
looks for $XDG_CONFIG_HOME/vim/vimrc on its own, no further hacks required.
We can move on to configuring inside our vimrc.
Configuration in vimrc
First of all, although not mandatory, let's set $MYVIMRC variable:
if empty($MYVIMRC) | let $MYVIMRC = expand('<sfile>:p') | endif
Let's define fallback locations in case XDG_* variables are not set.
if empty($XDG_CACHE_HOME) | let $XDG_CACHE_HOME = $HOME."/.cache" | endif
if empty($XDG_CONFIG_HOME) | let $XDG_CONFIG_HOME = $HOME."/.config" | endif
if empty($XDG_DATA_HOME) | let $XDG_DATA_HOME = $HOME."/.local/share" | endif
if empty($XDG_STATE_HOME) | let $XDG_STATE_HOME = $HOME."/.local/state" | endif
Let's add entries to runtimepath:
set runtimepath^=$XDG_CONFIG_HOME/vim
set runtimepath+=$XDG_DATA_HOME/vim
set runtimepath+=$XDG_CONFIG_HOME/vim/after
$XDG_CONFIG_HOME/vim and $XDG_CONFIG_HOME/vim/after are just equivalents of
~/.vim and ~/.vim/after, but $XDG_DATA_HOME/vim is brand new - there we
will keep downloadables (like plugins and spell files), Netrw bookmarks etc.
Let's set directory for Vim8 build-in packages:
set packpath^=$XDG_DATA_HOME/vim
set packpath+=$XDG_DATA_HOME/vim/after
Netrw is just as easy:
let g:netrw_home = $XDG_DATA_HOME."/vim"
What about spellings? Well, this one is more tricky, because it isn't controlled
by any option. Instead, it searches for spell directory in whole runtime path.
If none is found then it falls back to ~/.vim/spell. So let's create one at
desired location ourselves!
So far so good. We are left with state (backup, undo, swap, viminfo, view).
Vim doesn't create directories for them (even for defaults), so we will need
to do it ourselves - luckily VimL offers mkdir() function:
set backupdir=$XDG_STATE_HOME/vim/backup | call mkdir(&backupdir, 'p', 0700)
set directory=$XDG_STATE_HOME/vim/swap | call mkdir(&directory, 'p', 0700)
set undodir=$XDG_STATE_HOME/vim/undo | call mkdir(&undodir, 'p', 0700)
set viewdir=$XDG_STATE_HOME/vim/view | call mkdir(&viewdir, 'p', 0700)
if !has('nvim') " Neovim has its own location which already complies with XDG specification
set viminfofile=$XDG_STATE_HOME/vim/viminfo
endif
Congratulations!
Now your Vim is configured with accordance to XDG Base Directory specification.
