Note that TrustZone is also not without its security issues as a result of running on the same core. For example, there was a recent vulnerability that found that the non-secure code (i.e. the OS) had control over the power management parts and so could drop power to the core as it enters secure mode and trigger bit flips in registers. I don't know if anyone has managed to get a working proof-of-concept exploit for this yet, but there are several JVM escapes that rely on a single bit flip.
It's actually a shame that there isn't some anonymised collection of this data. Talking to a cardiologist friend a few months ago, one of the biggest problems that they have is that they don't actually know what a regular heartbeat looks like. Lost of people are diagnosed with heart problems and then wear a monitor, but no one sticks heart monitors on healthy people for a few months to get a good baseline. What the discipline really needs is a few thousand healthy people to wear a heart monitor for a year. They suspect that various forms of arrhythmia are actually quite common and not life threatening, but they have to assume that they are because the only times that they see them are when people have been specifically referred to a cardiologist.
I've moved to Let's Encrypt (which, with acme-client is a bit easier to use) for TLS certs for web servers, but I've not found an alternative for issuing trusted S/MIME certs. This was the most useful thing for StartCom: their S/MIME certs were trusted by all major mail clients, so if you signed your mail with them then you got tamper detection.
I don't really have a problem with revoking StarCom's root cert, but it does feel a little bit like singling out the Chinese. Why is COMODO still trusted after they were shown to have terrible security, Symentec after they were handing out certs for google.com to random people and a number of other dubious practices, and the Turkish and Iranian CAs after they were caught signing anything their respective intelligence agencies asked them to? Most of these sound more severe than StartCom's lapses, yet I note that all four of these are still in the default-trusted set for Google, Mozilla, and so on. I'd love to see the standards enforced more vigorously, but uniformly.
It's quite surprising. The FreeBSD Journal has some sponsorship from the FreeBSD Foundation (though I think it's now mostly self-supporting) as a marketing tool. A bunch of the articles exist to showcase the OS and provide a tool for people in IT departments to advocate within their organisation ('look, bigger-than-us company is using it to solve this problem we have!'). I'm a bit surprised that companies like RedHat don't find enough of a value in this to be able to bankroll it. That said, perhaps Linux now has enough mindshare in corporate IT that it's not really necessary.
I presume he is talking about macOS, iOS, and Android (and possibly ChromeOS). These add up to a pretty sizeable chunk of market share, but X11 isn't on any of them (at least, not by default and not as the primary display server).
That's a very shortsighted view. Corporations benefit from things that increase their ability to do business. Individuals benefit from some of the things that corporations do and are harmed by others. If something makes it easier for corporations to do business then that alone gives you no information about whether it's going to benefit you.
The problem is that a data cap is a really poor approximation of the cost. The time at which you use the data is a lot more relevant to the amount. If you download at 1Gb/s when no one else is using the network, then that's not really a problem. The problem with Netflix is that people tend to watch TV at similar times, so it is both high-bandwidth per customer and at peak time.
Power and water are not sold like that. I don't pay a flat rate for an advertised 30A power supply to my house on the assumption that my average will be 300mA and that I'll burst to 30A, I pay for the amount that I consume. The same for water.
This typically isn't done for network connections, because the cost of providing the service is not proportional to how much you use, it's proportional to the peak load on the network. At off-peak times, there's no extra cost if you allow someone to saturate their connection, but at peak times you may only have enough off-net bandwidth (or second-hop bandwidth) to allow everyone to get 50% or less of their peak.
The biggest problem that I have with ISPs is not that they charge this way, but that they advertise in a misleading way. They advertise unlimited 100Mb/s (or whatever), when what they mean is '100Mb/s peak, 1Gb/s off-net bandwidth per 10 customers' or similar. ISPs here used to advertise contention ratios (and have different tiers for different contention ratios), but this ended when they realised that the ratios they were not comparable.
You are misunderstanding how Google works. They are only in one market: advertising. Everything else that they are doing is for the sole purpose of providing new places to put adverts. But if you really want another example, how about the Play store (which exists to ensure that Play services and therefore Google ads are on every Android phone and integrated into most Android apps)? It has an overwhelming market share of Android app stores and a large majority of the overall smartphone app store market.
Most small businesses are in this situation. There was a time when small software companies dreaded the call from Microsoft: they'd get an offer to buy the company, and if they didn't accept it then Microsoft would ship a competing product that they were able to throw more engineers at and a lot more marketing money at.
The problem with Facebook and Microsoft as competitors here is that they already typically have access to a superset of your customers. If you were developing Windows software and Microsoft wanted to compete with you, not only were all of your customers already their customers, but all of your potential customers were as well. This put them in a far stronger position than you, even if they were developing the product from scratch. Facebook is often in a similar situation.
If you want to be technical, this is a vulnerability. An exploit is something that (as its name implies) exploits a vulnerability (which is a category of bug that can be used by exploits).
It's pretty common to do on BSD systems, because there are a bunch of things that add extra checks for blank passwords and so effectively disable use of the root account. For example, SSH won't allow root login if the root password is blank. Only members of the wheel group can su to root and if you put users in a sudo-enabled group but not in wheel then no one can su to root. If you can mark consoles as insecure then root login is disabled by default on them. This basically leaves you with booting to single user mode as the only way of logging in as root. This is basically the setup that macOS uses: the root account is effectively disabled by setting the password to blank (modulo bugs like this).
Meanwhile, there's been a "Shada" reconstruction (with all the shot-at-the-time footage, and Baker doing talking-head narration of the missing bits) around for ages.
The BBC also did an animated version that was available on their web site over 10 years ago that had Richard E. Grant as The Doctor. I was sad they didn't get him for the revivals - he was great in that and some of the Big Finish productions. Mind you, I'm also annoyed that they didn't go with Sue Perkins as the new Doctor when she was by far the best of the rumoured candidates.
Basically everything regarding padding - and even ordering of fields - is implementation dependent and not specified in any standard.
There are two relevant standards: the C language standard and the platform ABI standard. C compilers must comply with both for anything that is intended to interoperate. The platform ABI standard places much stricter requirements on structure layout than the language standard. This is important because the following is allowed in C (from your example):
In one compilation unit subtract a pointer to start of the struct from a pointer to the the l1 field and pass it to a function in another compilation unit.
In another compilation unit, construct a new instance of the same struct, cast the pointer to a char*, add the offset, and then cast it to a pointer to long, and assign to it.
The result of this must be a version of the struct with the l1 field assigned. This is a guarantee of the C language, and the platform ABI standard provides the rules that allow it to work between different compilation units from different compilers (e.g. in different libraries).
Oh, and the C standard actually does place some constraints that prevent the reordering that you describe. If you look at paragraph 6 of section 6.5.2.3, you'll see that, if a two structs start with the same fields then it is permitted to access the fields in either from a union. By induction, this means that struct fields must be ordered from the start, because anywhere else in the program (including other compilation units into which the compiler has no visibility) I can have structs that contained all of the prefixes of your struct (short, short long, short long short) and can declare a union of them and your struct and access the fields through them (and 6.7.2.1 paragraph 15 prevents there from being any padding at the start, so s1 must be at offset 0).
If you can compile a C++ program in less time than it takes to start Python, you either have a really slow Python interpreter or a really tiny C++ program! C++ is legendary for being slow to compile, and now that they have link-time code generation, even linking is slow!
I'm talking about really tiny C++ programs: A few dozen to a couple of hundred lines of code.
Part of the problem with C++ is that you have to compile a whole program. You can't compile libraries separately because even changing compiler options can make a lib no longer binary compatible. Is there any other language where you have to ship precompiled binaries but can't ship precompiled libraries?
That's only true on Windows. Every other OS has a standard C++ ABI and C++ libraries interoperate happily between compilers. Windows defines COM and C as the standard ABIs for libraries, but doesn't define a standard C++ ABI.
Please read my reply to the other poster. TL;DR: The C compiler is required to either add the padding required by the ABI, or prove that no pointers to the type escape from that compilation unit. It is not free to add padding to improve optimisation unless it can prove that no pointers to the type escape (which is typically impossible).
I don't think I'm misunderstanding what you're doing - I've seen a lot of novice C programmers try exactly the same approach and you're making a bunch of rookie errors:
You are writing an API that deals with C strings explicitly. This means that you're tying all consumers of your API into a single data representation at the API level, you can't even change the representation by recompiling, so you have tight coupling of API and data representation. This is bad software engineering.
You are losing one of the benefits of C/C++ by forcing all objects to be allocated on the heap. If your strings are mutable (which it looks as if they are, from your API description), you can't put them in globals, even when you have some that are probably never going to be modified, because that would break your API contract. C++ strings in a modern implementation gain a lot from being able to be allocated on the stack and modified without any heap allocations.
In the specific case of strings, the length of a string is always known at creation time. C didn't store the length of strings inline because storing a size_t in every string would have been too much overhead on machines where RAM was a lot more scarce than even most embedded systems today. This means that raw C string manipulation needs to recompute the length every time. Pretty much all other string libraries where anyone has cared about performance written in the last 30 years store the size in the string object. With your model, you say that you are getting the length at allocation time, but then you're not returning it and so the next function that uses it as an argument needs to recompute it.
For mutable strings, it is common to differentiate between the amount of allocated space and the amount of space in the string. This makes appending cheaper, because appending a few characters individually can be done without needing to reallocate each time, at the potential cost of some RAM.
String libraries that are intended to do a lot of concatenation use the twine model. The simplest form of twine is simply a linked list of strings. You can append strings in constant time and then do a single copy lazily to flatten later (if required). More complex versions use skip lists or similar for searching, but that's only needed if you want to support amortised constant time random access. Again, this is impossible to do if your exported data type is a C string. For comparison, look at LLVM's Twine family of classes, which implements the twine model and can use C or C++ strings as nodes, and will perform a single copy for the result of an arbitrary number of concatenate operations.
You are tying your memory management policy tightly to your API in such a way that effectively precludes data sharing. There is no way to add reference counted strings in your model, for example. If you implemented twines and kept appending the same string to a load of others, then the best way of doing that would be to have multiple references to a single string that's shared between all of them and then copy it when you flatten. It's also not possible to, for example, provide a zero-copy substring function.
Nope. No Intel mobile chip currently supports LPDDR4 or more than 16GB of LPDDR3. That said, apparently Dell is selling a machine with 32GB of DDR4L, which only uses about 10% more power than LPDDR4, and a lot less than DDR4. The IBM machine is either doing the same or using desktop RAM.
I've taken that approach, but it's very clunky and, importantly, it's hard to retrofit to a class where you initially made the decision one way or another (or the natural choice when first implementing a class). It feels like the way that you did compile-time computations in pre-C++11 days via templates. I would love to see something to make this more natural.
There's no (so far as I know) guarantee the compiler will put them in that order in the object code
There is no guarantee that the compiler will put them in the object code. There is, however, a guarantee that, if a pointer to one has escaped from a compilation unit then the layout will be the same for all compilation units (including, implicitly, ones that are in shared libraries that are dynamically loaded as plugins). In contrast, there is absolutely no guarantee of structure layout in Java, and typical JVM implementations sort the fields to have primitives and object references contiguous, to simplify GC.
Okay, three of you have jumped on that, so let me be more explicit:
A C compiler may add padding, but its ability to do so is constrained (or mandated) by the platform ABI. The layout of a struct is exposed directly in the language because you can ask for sizeof() the struct (which, if you subtract the size of all of the fields will tell you the total padding) and you cast a pointer to a field and a pointer to the struct to char*, subtract one from the other, and get the offset of each field. This means that it is effectively impossible for a C compiler to add padding to make optimisations easier (the only case in which they will reliably do it is for on-stack structs that are not address-taken).
That scenario isn't possible, as far as there is no string literal assignation. Rather than doing stringVar = "string literal", I always do stringVar = AssignStringLiteral_m(NULL, "string literal");. As said, all my code is extremely consistent and inter-compatible.
Okay, so the ownership semantics for the second argument (and later ones?) is always that of a non-owning pointer, so you must explicitly free it. Now you have a model where some things take an owning pointer and some take a non-owning pointer and you're relying on convention to make sure that you don't mix these up. I really hope that you've written a static checker to enforce this.
Why? All what I am doing is avoiding writing malloc, string copy, etc. every time and call methods performing those actions
You're still doing the malloc / copy, you're just doing it inside the function.
Are you saying that string operations in C are slower than in a scripting language?
No, a well-optimised string library in C (such as glib strings) will be faster than wrapping a well-optimised string library in a scripting language. In contrast, you're using a set of API design choices that preclude most of the common string processing optimisations. If you instead use a scripting language then you'll have some overhead from the interpreter, but your underlying implementation of the string (which is probably written in C or C++) will be a lot faster.
No idea where you are getting all that from what I have written so far. The only weak point of the described approach might be relying on malloc rather than on a quicker string definition, which is also associated with a much lower available space what isn't precisely ideal under my specific conditions (should be able to deal with strings of any size). I might take a further look at all this at a later stage to further optimise its performance; for the time being, my only concern was coming up with an approach allowing me to intuitively maximise the C performance and that seemed a quite acceptable trade-off.
Your design, using raw C strings, prevents you from storing a length separately (so you keep needing O(n) strlen calls), prevents you from implicitly sharing large strings (so you need O(n) copies) and prevents you from deferring copying using the twine optimisation (so you need more O(n) copies). It's such a case study in bad design that Raymond Chen wrote a blog about how not to do string processing 20 years ago describing it.
I don't get that reference. If you are really asking me whether I work for a company called Enlightenment, I am not.
Enlightenment is a window manager that has spawned the Enlightenment Foundation Libraries, a framework that is infamous for making design decisions like this that give them all of the performance of an interpreted scripting language combined with all of the type and memory safety of C.
Slashdot Mirror
Note that TrustZone is also not without its security issues as a result of running on the same core. For example, there was a recent vulnerability that found that the non-secure code (i.e. the OS) had control over the power management parts and so could drop power to the core as it enters secure mode and trigger bit flips in registers. I don't know if anyone has managed to get a working proof-of-concept exploit for this yet, but there are several JVM escapes that rely on a single bit flip.
It's actually a shame that there isn't some anonymised collection of this data. Talking to a cardiologist friend a few months ago, one of the biggest problems that they have is that they don't actually know what a regular heartbeat looks like. Lost of people are diagnosed with heart problems and then wear a monitor, but no one sticks heart monitors on healthy people for a few months to get a good baseline. What the discipline really needs is a few thousand healthy people to wear a heart monitor for a year. They suspect that various forms of arrhythmia are actually quite common and not life threatening, but they have to assume that they are because the only times that they see them are when people have been specifically referred to a cardiologist.
I've moved to Let's Encrypt (which, with acme-client is a bit easier to use) for TLS certs for web servers, but I've not found an alternative for issuing trusted S/MIME certs. This was the most useful thing for StartCom: their S/MIME certs were trusted by all major mail clients, so if you signed your mail with them then you got tamper detection.
I don't really have a problem with revoking StarCom's root cert, but it does feel a little bit like singling out the Chinese. Why is COMODO still trusted after they were shown to have terrible security, Symentec after they were handing out certs for google.com to random people and a number of other dubious practices, and the Turkish and Iranian CAs after they were caught signing anything their respective intelligence agencies asked them to? Most of these sound more severe than StartCom's lapses, yet I note that all four of these are still in the default-trusted set for Google, Mozilla, and so on. I'd love to see the standards enforced more vigorously, but uniformly.
It's quite surprising. The FreeBSD Journal has some sponsorship from the FreeBSD Foundation (though I think it's now mostly self-supporting) as a marketing tool. A bunch of the articles exist to showcase the OS and provide a tool for people in IT departments to advocate within their organisation ('look, bigger-than-us company is using it to solve this problem we have!'). I'm a bit surprised that companies like RedHat don't find enough of a value in this to be able to bankroll it. That said, perhaps Linux now has enough mindshare in corporate IT that it's not really necessary.
I presume he is talking about macOS, iOS, and Android (and possibly ChromeOS). These add up to a pretty sizeable chunk of market share, but X11 isn't on any of them (at least, not by default and not as the primary display server).
That's a very shortsighted view. Corporations benefit from things that increase their ability to do business. Individuals benefit from some of the things that corporations do and are harmed by others. If something makes it easier for corporations to do business then that alone gives you no information about whether it's going to benefit you.
The problem is that a data cap is a really poor approximation of the cost. The time at which you use the data is a lot more relevant to the amount. If you download at 1Gb/s when no one else is using the network, then that's not really a problem. The problem with Netflix is that people tend to watch TV at similar times, so it is both high-bandwidth per customer and at peak time.
Power and water are not sold like that. I don't pay a flat rate for an advertised 30A power supply to my house on the assumption that my average will be 300mA and that I'll burst to 30A, I pay for the amount that I consume. The same for water.
This typically isn't done for network connections, because the cost of providing the service is not proportional to how much you use, it's proportional to the peak load on the network. At off-peak times, there's no extra cost if you allow someone to saturate their connection, but at peak times you may only have enough off-net bandwidth (or second-hop bandwidth) to allow everyone to get 50% or less of their peak.
The biggest problem that I have with ISPs is not that they charge this way, but that they advertise in a misleading way. They advertise unlimited 100Mb/s (or whatever), when what they mean is '100Mb/s peak, 1Gb/s off-net bandwidth per 10 customers' or similar. ISPs here used to advertise contention ratios (and have different tiers for different contention ratios), but this ended when they realised that the ratios they were not comparable.
You are misunderstanding how Google works. They are only in one market: advertising. Everything else that they are doing is for the sole purpose of providing new places to put adverts. But if you really want another example, how about the Play store (which exists to ensure that Play services and therefore Google ads are on every Android phone and integrated into most Android apps)? It has an overwhelming market share of Android app stores and a large majority of the overall smartphone app store market.
Most small businesses are in this situation. There was a time when small software companies dreaded the call from Microsoft: they'd get an offer to buy the company, and if they didn't accept it then Microsoft would ship a competing product that they were able to throw more engineers at and a lot more marketing money at.
The problem with Facebook and Microsoft as competitors here is that they already typically have access to a superset of your customers. If you were developing Windows software and Microsoft wanted to compete with you, not only were all of your customers already their customers, but all of your potential customers were as well. This put them in a far stronger position than you, even if they were developing the product from scratch. Facebook is often in a similar situation.
If you want to be technical, this is a vulnerability. An exploit is something that (as its name implies) exploits a vulnerability (which is a category of bug that can be used by exploits).
It's pretty common to do on BSD systems, because there are a bunch of things that add extra checks for blank passwords and so effectively disable use of the root account. For example, SSH won't allow root login if the root password is blank. Only members of the wheel group can su to root and if you put users in a sudo-enabled group but not in wheel then no one can su to root. If you can mark consoles as insecure then root login is disabled by default on them. This basically leaves you with booting to single user mode as the only way of logging in as root. This is basically the setup that macOS uses: the root account is effectively disabled by setting the password to blank (modulo bugs like this).
They did both, and Real Time. It looks as if it's still online.
Meanwhile, there's been a "Shada" reconstruction (with all the shot-at-the-time footage, and Baker doing talking-head narration of the missing bits) around for ages.
The BBC also did an animated version that was available on their web site over 10 years ago that had Richard E. Grant as The Doctor. I was sad they didn't get him for the revivals - he was great in that and some of the Big Finish productions. Mind you, I'm also annoyed that they didn't go with Sue Perkins as the new Doctor when she was by far the best of the rumoured candidates.
Basically everything regarding padding - and even ordering of fields - is implementation dependent and not specified in any standard.
There are two relevant standards: the C language standard and the platform ABI standard. C compilers must comply with both for anything that is intended to interoperate. The platform ABI standard places much stricter requirements on structure layout than the language standard. This is important because the following is allowed in C (from your example):
In one compilation unit subtract a pointer to start of the struct from a pointer to the the l1 field and pass it to a function in another compilation unit.
In another compilation unit, construct a new instance of the same struct, cast the pointer to a char*, add the offset, and then cast it to a pointer to long, and assign to it.
The result of this must be a version of the struct with the l1 field assigned. This is a guarantee of the C language, and the platform ABI standard provides the rules that allow it to work between different compilation units from different compilers (e.g. in different libraries).
Oh, and the C standard actually does place some constraints that prevent the reordering that you describe. If you look at paragraph 6 of section 6.5.2.3, you'll see that, if a two structs start with the same fields then it is permitted to access the fields in either from a union. By induction, this means that struct fields must be ordered from the start, because anywhere else in the program (including other compilation units into which the compiler has no visibility) I can have structs that contained all of the prefixes of your struct (short, short long, short long short) and can declare a union of them and your struct and access the fields through them (and 6.7.2.1 paragraph 15 prevents there from being any padding at the start, so s1 must be at offset 0).
If you can compile a C++ program in less time than it takes to start Python, you either have a really slow Python interpreter or a really tiny C++ program! C++ is legendary for being slow to compile, and now that they have link-time code generation, even linking is slow!
I'm talking about really tiny C++ programs: A few dozen to a couple of hundred lines of code.
Part of the problem with C++ is that you have to compile a whole program. You can't compile libraries separately because even changing compiler options can make a lib no longer binary compatible. Is there any other language where you have to ship precompiled binaries but can't ship precompiled libraries?
That's only true on Windows. Every other OS has a standard C++ ABI and C++ libraries interoperate happily between compilers. Windows defines COM and C as the standard ABIs for libraries, but doesn't define a standard C++ ABI.
C has had a _Bool type for 18 years and a stdbool.h header that defines bool to be _Bool.
Please read my reply to the other poster. TL;DR: The C compiler is required to either add the padding required by the ABI, or prove that no pointers to the type escape from that compilation unit. It is not free to add padding to improve optimisation unless it can prove that no pointers to the type escape (which is typically impossible).
You are writing an API that deals with C strings explicitly. This means that you're tying all consumers of your API into a single data representation at the API level, you can't even change the representation by recompiling, so you have tight coupling of API and data representation. This is bad software engineering.
You are losing one of the benefits of C/C++ by forcing all objects to be allocated on the heap. If your strings are mutable (which it looks as if they are, from your API description), you can't put them in globals, even when you have some that are probably never going to be modified, because that would break your API contract. C++ strings in a modern implementation gain a lot from being able to be allocated on the stack and modified without any heap allocations.
In the specific case of strings, the length of a string is always known at creation time. C didn't store the length of strings inline because storing a size_t in every string would have been too much overhead on machines where RAM was a lot more scarce than even most embedded systems today. This means that raw C string manipulation needs to recompute the length every time. Pretty much all other string libraries where anyone has cared about performance written in the last 30 years store the size in the string object. With your model, you say that you are getting the length at allocation time, but then you're not returning it and so the next function that uses it as an argument needs to recompute it.
For mutable strings, it is common to differentiate between the amount of allocated space and the amount of space in the string. This makes appending cheaper, because appending a few characters individually can be done without needing to reallocate each time, at the potential cost of some RAM.
String libraries that are intended to do a lot of concatenation use the twine model. The simplest form of twine is simply a linked list of strings. You can append strings in constant time and then do a single copy lazily to flatten later (if required). More complex versions use skip lists or similar for searching, but that's only needed if you want to support amortised constant time random access. Again, this is impossible to do if your exported data type is a C string. For comparison, look at LLVM's Twine family of classes, which implements the twine model and can use C or C++ strings as nodes, and will perform a single copy for the result of an arbitrary number of concatenate operations.
You are tying your memory management policy tightly to your API in such a way that effectively precludes data sharing. There is no way to add reference counted strings in your model, for example. If you implemented twines and kept appending the same string to a load of others, then the best way of doing that would be to have multiple references to a single string that's shared between all of them and then copy it when you flatten. It's also not possible to, for example, provide a zero-copy substring function.
Nope. No Intel mobile chip currently supports LPDDR4 or more than 16GB of LPDDR3. That said, apparently Dell is selling a machine with 32GB of DDR4L, which only uses about 10% more power than LPDDR4, and a lot less than DDR4. The IBM machine is either doing the same or using desktop RAM.
I've taken that approach, but it's very clunky and, importantly, it's hard to retrofit to a class where you initially made the decision one way or another (or the natural choice when first implementing a class). It feels like the way that you did compile-time computations in pre-C++11 days via templates. I would love to see something to make this more natural.
There's no (so far as I know) guarantee the compiler will put them in that order in the object code
There is no guarantee that the compiler will put them in the object code. There is, however, a guarantee that, if a pointer to one has escaped from a compilation unit then the layout will be the same for all compilation units (including, implicitly, ones that are in shared libraries that are dynamically loaded as plugins). In contrast, there is absolutely no guarantee of structure layout in Java, and typical JVM implementations sort the fields to have primitives and object references contiguous, to simplify GC.
A C compiler may add padding, but its ability to do so is constrained (or mandated) by the platform ABI. The layout of a struct is exposed directly in the language because you can ask for sizeof() the struct (which, if you subtract the size of all of the fields will tell you the total padding) and you cast a pointer to a field and a pointer to the struct to char*, subtract one from the other, and get the offset of each field. This means that it is effectively impossible for a C compiler to add padding to make optimisations easier (the only case in which they will reliably do it is for on-stack structs that are not address-taken).
That scenario isn't possible, as far as there is no string literal assignation. Rather than doing stringVar = "string literal", I always do stringVar = AssignStringLiteral_m(NULL, "string literal");. As said, all my code is extremely consistent and inter-compatible.
Okay, so the ownership semantics for the second argument (and later ones?) is always that of a non-owning pointer, so you must explicitly free it. Now you have a model where some things take an owning pointer and some take a non-owning pointer and you're relying on convention to make sure that you don't mix these up. I really hope that you've written a static checker to enforce this.
Why? All what I am doing is avoiding writing malloc, string copy, etc. every time and call methods performing those actions
You're still doing the malloc / copy, you're just doing it inside the function.
Are you saying that string operations in C are slower than in a scripting language?
No, a well-optimised string library in C (such as glib strings) will be faster than wrapping a well-optimised string library in a scripting language. In contrast, you're using a set of API design choices that preclude most of the common string processing optimisations. If you instead use a scripting language then you'll have some overhead from the interpreter, but your underlying implementation of the string (which is probably written in C or C++) will be a lot faster.
No idea where you are getting all that from what I have written so far. The only weak point of the described approach might be relying on malloc rather than on a quicker string definition, which is also associated with a much lower available space what isn't precisely ideal under my specific conditions (should be able to deal with strings of any size). I might take a further look at all this at a later stage to further optimise its performance; for the time being, my only concern was coming up with an approach allowing me to intuitively maximise the C performance and that seemed a quite acceptable trade-off.
Your design, using raw C strings, prevents you from storing a length separately (so you keep needing O(n) strlen calls), prevents you from implicitly sharing large strings (so you need O(n) copies) and prevents you from deferring copying using the twine optimisation (so you need more O(n) copies). It's such a case study in bad design that Raymond Chen wrote a blog about how not to do string processing 20 years ago describing it.
I don't get that reference. If you are really asking me whether I work for a company called Enlightenment, I am not.
Enlightenment is a window manager that has spawned the Enlightenment Foundation Libraries, a framework that is infamous for making design decisions like this that give them all of the performance of an interpreted scripting language combined with all of the type and memory safety of C.