It's quite astonishing how the historical inability of commonly used programming languages (from FORTRAN all the way to, say, Java/C#) to ergonomically return two values from a function call has caused people to invent all kinds of insane APIs/contracts.
[double x, errno_t errno] = strtod(s, nullptr);
if (errno != 0) {
// ...
}
[x, _] = strtod(s, nullptr); // When you're certain the error is impossible or just don't care
Instead, we're stuck with "check if the return value is -1 and if it is, check the global variable errno" at best, and with "the function doesn't really reliably reports its errors so don't feed it malformed data, idc" at worst.
> Needing to typedef a unique struct for every possible function return type isn't very ergonomic, but you can work around that with C23:
I think you’ve unraveled the mystery of why that didn’t catch on in nearly 40 years of C.
Honestly it’s got to be the biggest disappointment in computer science that nothing has displaced C as the Franca Lingua. And now with the advent of AI, I don’t think anyone is going to care anymore. Rust will be the future, but not because it’s ergonomic, but because it can prevent memory errors.
In C you can return a struct with two members. The reason the standard library doesn’t do this isn’t ergonomics, it’s performance, or maybe the traditional inability of compilers to map it to what would be the idiomatic register assignment, due to how ABIs are defined.
C++/C#/Python absolutely do have ergonomic ways to do this (and have for decades by this point...) but programmers continue to use sentinel values. It is a bit puzzling.
Java and C# famously solve this with a hidden implicit return value for errors: the exception. The current trend in language design is to take the same idea and make it explicit instead, using sum types. Like Rust's `Result`, where the result contains either the normal value or an error, but never both
Of course C++ gives you the option to do any of the above, and still contains insane API contracts
That doesn't solve the whole problem, though - as per the rule, "zero, one, infinity", you often want to return more than two values, and often none of them represents an error.
Arguably the better solution compared to these "algebraic sum types" (they go by countless different names) are set-theoretic union types, used by a few languages such as TypeScript.
They allow for types like "String or Integer". A function which returns a value of type "A" can automatically also be assigned to a variable of type "A or B", and a function which accepts a parameter of type "A or B" can automatically also be passed a variable of type "A". This is not the case for algebraic sum types, which require somewhat inconvenient wrapping or unwrapping.
Unlike algebraic sum types, set-theoretic union types are also not necessarily mutually exclusive. E.g. a number of type "Integer or Float" could be both. Moreover, set-theoretic types can be generalized to arbitrary Boolean combinations of types, e.g. "A or (B and not C)", possibly involving disjunctions, conjunctions, and negations (since {and, or, not} are functionally complete). That's not possible for algebraic sum/product data types. Though there is no mainstream language yet with a set-theoretic type system that supports negation types.
> MLstruct supports union, intersection, and complement (or negation) connectives. We make sure they form a Boolean algebra and add enough structure to derive a sound and complete type inference algorithm. For more details, please see the paper mentioned above.
This is cool. Unfortunately it's also too late now. The machines have taken over programming.
This choice has nice ergonomics but brutal practical cost so that's why languages close to the metal do not want to do this and particularly don't want to go around defaulting to it whereas a language like Typescript is fine with it.
Maybe it has "brutal practical cost", I don't know, but even most high-level languages don't have set-theoretic type systems. Perhaps because the approach is relatively new and most popular languages are old.
C# got Tuple only in version 7.0 which was released in 2017, if you don't know; while TryParse has been there since 1.0 in 2002. And I'd still prefer to have e.g.
This golangism hurts readability, it puts an important piece of logic at the end of a pontentially long line. Usually, it's just an ok test, but it's easy to miss when it isn't.
When I write C I tend to always return any error code on the stack and pass the pointer to where I want the result to go. Makes managing memory easier. The owner gets to allocate.
Example:
#define E_DIVZERO -100
int divide(float a, float b, float *result) {
if (b == 0.0) return E_DIVZERO;
*result = a / b;
}
typedef struct {
int status;
float value;
} div_result_t;
div_result_t divide(float a, float b) {
if (b = 0.0) return (div_result_t){ E_DIVZERO };
return (div_result_t){ 0, a / b };
}
On SYSV: The `status` gets returned in x0/rax, and `value` gets returned in x1/xmm0.
On MSVC: The caller allocates `sizeof(div_result_t)` on the stack, passes the the pointer to that space as an implicit first argument to `divide` in register x0/rcx. The function returns the same pointer as its result in x0/rax.
The latter is almost equivalent to you passing a pointer manually - but the compiler does it for you. In the former case, it's actually more efficient to use the struct as we don't even need to touch the stack - all arguments and returns are in registers (for structs up to two "eightbytes" - ie, 16-bytes).
IMO, if it intended to use automatic storage duration, and the size of the struct is small enough, returning by value is preferable - it performs better on SYSV, and basically automates what you would do manually on MSVC. If it is intended for manual storage duration, then yes, use pass and return by pointer explicitly.
Is returning 2 values from a function ever required ?
If your code is organized well, and your functions act on context structures, a pass/fail result, or an error code where 0 = success, and everything else is an error, or a pointer to a structure with multiple values, seems to be entirely sufficient.
I quite prefer C, over C++ and other perhaps "more expressive" languages, exactly because it is simpler. It does more with less.
"It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." - Albert Einstein
So, returning 2 values is more performant than returning 1.
How does this affect branch prediction ?
When code is structued:
...
result = function1(arg1,arg2,etc);
if ( !result ) handle_error(result);
result = function2(arg1,arg2,etc);
if ( !result ) handle_error(result);
...
branch prediction performs well.
I guess if you're checking and branching on 2 values, it performs twice as well ?
`foo` is slightly more efficient than `bar` on 64-bit SYSV, whose ABI supports 128-bit ("two eightbytes") returns in hardware registers. `bar` requires at least one dereference to assign the result.
On other compilers this isn't the case. MSVC only supports 64-bit returns and would use the stack for `option_int_t`. The caller allocates the space and an implicit pointer is passed in the first argument register (eg, `rcx`), and the same pointer is returned as the result.
Heck, even using multiple returns for this feels like a kludge to me at this point, when more advanced languages like TypeScript, Rust or Zig offer sum types/tagged unions.
Except often you want disjoined return arguments, while sum types setup an either-or situation. You can resort to tuples/arrays, but then that questions why the languages support multiple input arguments when tuples can be equally used for input. Frankly, any language that accepts multiple input arguments but only allows one return argument didn't have much thought put into it.
I'd argue it's as much a mentality as language barrier; high assurance code would typically always return an error code, and use out parameters rather than return values. This has been possible for as long as C has existed (I imagine), it's just not common practice.
I have a pet theory that new languages benefit at least as much from an opportunity to reset "common practice" / defaults as they do syntax/semantic improvements.
C allows struct returns, and C++ allows something quite close to what you've written verbatim. But in 1989, there was less of a focus on error handling; most code wasn't checking errno at all, so why spend time returning it to every caller?
typedef struct {
double value;
int error;
} maybe_double;
Is most efficient on x86-64 SYSV, because the ABI supports the `error` being returned in a GP register, and the `value` in a vector register. The struct is returned in `rax:xmm0` - the double is where it is meant to be.
When you use a union containing an int and a double, the double has to be moved to a GP register, and back to the vector register when read as a double (via movq), so there's a small hidden cost compared to the former approach. Your `Result_double` is returned in `rax:rdx`.
There's a trick you can use to avoid this - keep the `double` in the vector register and move the `int` to the vector register instead - so you only pay the cost to move between GP and vector registers when there's an error but not otherwise. To do this, make the union use `__m64` instead of `int` - the whole union is then in a vector register, and the `Result_double` struct is returned in `rax:xmm0`, as with `maybe_double` struct.
Of course, this is x86-64 SYSV only. On AARCH64, the double will always be moved to a GP register in either example. Other conventions may also differ - MSVC in particular is poor because it converts to pass-by-pointer to a stack allocated structure for any struct greater than 64-bits.
On MSVC we could maybe get maximum efficiency by using NaN-boxing - store the error code in the signalling NaN space - eg, treat NaNs beginning 0x7FF1 as error codes.
Basically all commonly used languages support this nowadays. Even ones you might not expect like C++ and C# have added it. The only major exceptions that come to mind are C and Java.
C number parsing functions are fundamentally broken, since they are locale-dependend. There are many bugs when one parses a number assuming it has decimal point, but later on systems with locale different from one used on developer's machine it may be suddenly comma instead of point. So, one should avoid using them almost always and use std::from_chars (available in new C++ versions) or some other thirdparty library.
When I was writing some ASM for a microcontroller to do string <--> float conversion, I could find almost nothing on how to best perform the operations.
There were essentially three ways to do it. Muddle through with a naive implementation. Look at the ASM of an old 8-bit machine. The final category was the by far the most dominant suggestion, to the point that anything else is almost like lost knowledge now. That solution was to use the C standard functions.
It seems like this is a sufficiently unpleasant task that as soon as anyone didn't absolutely have to do it all themselves, the punted to a black box solution.
There's probably something to be said there about the plethora of hobbiest 3d engines in comparison.
For good reasons. The VAX floating point specification was much worse, even if somewhat cheaper to implement.
IEEE 754 was one of the few standards that caused a significant progress of the standardized domain, because what is important for users had precedence over what is important for vendors.
Before IEEE 754, all floating-point implementations attempted to minimize the hardware cost, regardless of what aberrant behavior this would cause, which would confuse the naive users.
Even putting aside the ugliness of errno, this is pretty bad. I'm at the point with libc where I try to use as little of it as I can, though I'm not writing a lot of C these days
I would say there are 3 broad classes of libc functions
1) functions that you cannot implement in portable C - syscalls, signals, ABI specific things like longjmp and setcontext
2) functions that you could implement by yourself in portable C, but they are expected to play nice with the rest of the system - a lot of POSIX user stuff, dns management, dlopen, all the nsswitch mess. Can't think of any standard C examples because of the extreme portability requirements of C. Maybe the locale stuff, although it's usefulness is dubious.
3) functions that are there for convenience and sometimes compiler special-casing, like math, str*, <db.h> stuff that was thankfully removed from glibc
Most of #3 should be ignored. #2 is optional, especially if your software is for end users and not packaged by a distro. Sometimes it's safer to ship your own MDNS implementation for example rather than hope that the distro has sane defaults.
I'd much rather push for a world where we use a reasonable DNS/mDNS implementation on Linux rather than add to the zoo of bespoke variants. I have written code that tries to appease different DNS managers across different versions of them for different distros. We need to stop. Everyone believes that the common way of handling DNS is insane, so they create their own new way of doing it.
Sometimes I wish we could get to a timeline where the FPU format standards have something like Crockford’s DEC64 end up winning or evolving into the prevailing standard. Simpler & consistent math ought not to be this hard.
Just don't make the errors, then you don't have to detect them.
When your app stops issuing these errors, then you won't have to write blog posts complaining that someone elses code can't handle your errors.
Definitely you should never be converting strings to floats ever anyways, see how I'm going on a limb here without any knowledge of your application, but then you know that I'm right because there's no reason why you would ever do that?
That doesn't detect overflows and underflows. Also changes based on locale, which is not thread safe (so you cannot set locale, convert, then unset locale).
That's a feature: Where did the string come from if not the user?
> you cannot set locale, convert, then unset locale
So what? You're not handling multiple locales: You're using the user's locale. If you're making a server, using anything but LANG=C or a utf8 variant is asking for trouble.
I think the point is it's absolutely possible to portably detect errors, some libc's strtod() just don't which ain't the same thing.
> That's a feature: Where did the string come from if not the user?
Many games and applications store floating point values in text file formats. This has caused bugs in those programs many times over because they didn't realise it was locale dependent and the data parsing broke in another locale.
I don't support the nonstandard use of commas as decimal points in my software, so that's not an issue for me. That's a hill for the Europeans to live and die on. "Gotta be different from everybody else" has a price.
Ah, yes, the Azerbaijanis and the Belorussians, can't forget them. About 27% of the world population in total, if the clanker's more detailed report is to be believed.
Regardless, it's goofy. Everybody should agree on one or the other, and it's too late for the other 73% to switch.
> Many games and applications store floating point values in text file formats.
And why, pray tell, would those games and applications ship with text files containing floating point values that were invalid?
Certainly if they produce the values, strtod() is sure to work, and worrying about errors at that level just doesn't make any sense at all.
> This has caused bugs in those programs
I'm sorry this just isn't true: The programmer caused the bugs in those programs and nobody else.
Meanwhile users who produce text files with floating point numbers in their locale expect program that load those text files to tolerate their locale, and those programs should not be using strtod()!
The floating point values were valid, they were stored in the text files (unknowingly) in a locale dependent way, either by having a program use a locale sensitive functions to write the values, or because the values were written by hand using the developer's native way of number formatting. The values were then read using the locale dependent functions (like strtod) and if run on a machine with a locale that formatted numbers differently (i.e. using comma for decimal separator) they would return incorrect values.
This caused issues in the game as the values would be significantly different than originally designed, and it would be hard to test for since the people testing the game would usually be using a similar locale to the developer writing the game, and therefore they would only become apparent upon release or wider testing. Now the fix was to explicitly specify the locale before reading the data files, but it still took time to find and implement the fix.
I would not agree. That sounds to me like the floating point values were not valid, because they were stored in the user's locale and were not intended for the user themselves to consume, but for the developer (who is not the user), or another person (who is also not the user, even if they are a user).
I understand maybe they "should be" valid, but they weren't, and the programmer should not have written files in the users locale that they did not expect the user to edit personally; that they intended to consume mechanically, even if they found it convenient as a human being to edit the file on occasion.
> differently (i.e. using comma for decimal separator) they would return incorrect values.
My suggestion reports an error. strtod() can also detect this error (that's what the second argument is for), so the programmer was not checking if they were using strtod(). This is also not the kind of error the article is talking about detecting.
I don't think you understand the situation so I'll try explaining it one last time.
The developer stored floating point values in a text file written out by whatever means, in the developer's locale (say en-US). These files were shipped with the application and the values were read in using locale sensitive functions on a user's machine (the developer was unaware of the locale sensitive nature of these functions), and the user's locale was something different like de-DE for example. This resulted in a different value being read in compared to the value expected by the developer, therefore causing issues in the rest of the program.
For example the file stored "1.05" which in the developer's en-US locale is "one and five hundredths", but reading it on a different user's locale (de-DE) could result in the value being "105" (one hundred and five), or even "1" (one).
These files are generally not considered to be edited by users (unless they are modding the game, and then they do so without warranty etc).
Annoyingly this doesn't detect certain errors. This is one thing I'd like to change in the next C standard, but (from discussions I had with someone who works in those standards) they don't want to break existing code. Which seems like a very bogus justification to me as that code is broken already.
Also the locale thing could be solved by adding another %-directive to say "this format string should be treated in the C locale", like %C (if it's not already used).
IOW this could be made to work, but human factors prevent it.
On my machine it detects overflows just fine, returning Inf and -Inf, and also correctly rounds underflows to 0 and -0. But the function itself still returns 1 for overflows/underflows, so it's up to the caller to filter out infinities.
I guess that backs up the complaint about portability, if sscanf() doesn't behave that way on all platforms. But on MSVC its behavior is reasonable enough.
> No portable way to detect string-to-float conversion errors in standard C
There isn't just 1 standard C, theres many. AI says theres 5.
There are 5 major ISO C standards: C90, C99, C11, C17/C18, and C23. C89 is essentially the same standard as C90 under its ANSI name, and C95 was an amendment rather than a separate major edition. The latest is C23.
POSIX, as you know, stands for "Portable Operating System Interface."
> posix doesn't give a shit about math_errhandling; it always requires the implementation to set errno if overflow or underflow occurs.
So, POSIX, the "Portable" interface, specifies that underflow/overflow errors are always reported.
The problem seems to be in the headline, not the spec.
It's quite astonishing how the historical inability of commonly used programming languages (from FORTRAN all the way to, say, Java/C#) to ergonomically return two values from a function call has caused people to invent all kinds of insane APIs/contracts.
Instead, we're stuck with "check if the return value is -1 and if it is, check the global variable errno" at best, and with "the function doesn't really reliably reports its errors so don't feed it malformed data, idc" at worst.C has supported struct returns since at least C89:
Needing to typedef a unique struct for every possible function return type isn't very ergonomic, but you can work around that with C23:> Needing to typedef a unique struct for every possible function return type isn't very ergonomic, but you can work around that with C23:
I think you’ve unraveled the mystery of why that didn’t catch on in nearly 40 years of C.
Honestly it’s got to be the biggest disappointment in computer science that nothing has displaced C as the Franca Lingua. And now with the advent of AI, I don’t think anyone is going to care anymore. Rust will be the future, but not because it’s ergonomic, but because it can prevent memory errors.
In C you can return a struct with two members. The reason the standard library doesn’t do this isn’t ergonomics, it’s performance, or maybe the traditional inability of compilers to map it to what would be the idiomatic register assignment, due to how ABIs are defined.
C++/C#/Python absolutely do have ergonomic ways to do this (and have for decades by this point...) but programmers continue to use sentinel values. It is a bit puzzling.
Java and C# famously solve this with a hidden implicit return value for errors: the exception. The current trend in language design is to take the same idea and make it explicit instead, using sum types. Like Rust's `Result`, where the result contains either the normal value or an error, but never both
Of course C++ gives you the option to do any of the above, and still contains insane API contracts
That doesn't solve the whole problem, though - as per the rule, "zero, one, infinity", you often want to return more than two values, and often none of them represents an error.
I would not describe exceptions as return values. Speaking in a C context, exceptions are more like "longjmp" than "return".
They're both ! Exception are definitely viewed as an alternate communication channel. And stack unwinding is one aspect of the communication. See https://nedbatchelder.com/text/exceptions-vs-status#h_valuab... (and many other)
Arguably the better solution compared to these "algebraic sum types" (they go by countless different names) are set-theoretic union types, used by a few languages such as TypeScript.
They allow for types like "String or Integer". A function which returns a value of type "A" can automatically also be assigned to a variable of type "A or B", and a function which accepts a parameter of type "A or B" can automatically also be passed a variable of type "A". This is not the case for algebraic sum types, which require somewhat inconvenient wrapping or unwrapping.
Unlike algebraic sum types, set-theoretic union types are also not necessarily mutually exclusive. E.g. a number of type "Integer or Float" could be both. Moreover, set-theoretic types can be generalized to arbitrary Boolean combinations of types, e.g. "A or (B and not C)", possibly involving disjunctions, conjunctions, and negations (since {and, or, not} are functionally complete). That's not possible for algebraic sum/product data types. Though there is no mainstream language yet with a set-theoretic type system that supports negation types.
Sum types in the set theoretic approach can be made with `(A & ¬B) | (¬A & B)`, or equivalently `(A | B) & (¬A | ¬B)`.
There's no mainstream language with negation types, but a few good research languages with them, eg MLstruct.
[MLstruct]:https://github.com/hkust-taco/mlstruct
> MLstruct supports union, intersection, and complement (or negation) connectives. We make sure they form a Boolean algebra and add enough structure to derive a sound and complete type inference algorithm. For more details, please see the paper mentioned above.
This is cool. Unfortunately it's also too late now. The machines have taken over programming.
This choice has nice ergonomics but brutal practical cost so that's why languages close to the metal do not want to do this and particularly don't want to go around defaulting to it whereas a language like Typescript is fine with it.
Maybe it has "brutal practical cost", I don't know, but even most high-level languages don't have set-theoretic type systems. Perhaps because the approach is relatively new and most popular languages are old.
Wut? C# besides all other ways to return Tuples, Result<T>s, NULLable, etc, etc.
Still had something as sane as:
if (double.TryParse("5.x5", out var val)) { Console.WriteLine(val); } else { Console.WriteLine("err"); }
C# got Tuple only in version 7.0 which was released in 2017, if you don't know; while TryParse has been there since 1.0 in 2002. And I'd still prefer to have e.g.
Of course, having "var" there would be even nicer.This golangism hurts readability, it puts an important piece of logic at the end of a pontentially long line. Usually, it's just an ok test, but it's easy to miss when it isn't.
When I write C I tend to always return any error code on the stack and pass the pointer to where I want the result to go. Makes managing memory easier. The owner gets to allocate.
Example:
If you do:
On SYSV: The `status` gets returned in x0/rax, and `value` gets returned in x1/xmm0.On MSVC: The caller allocates `sizeof(div_result_t)` on the stack, passes the the pointer to that space as an implicit first argument to `divide` in register x0/rcx. The function returns the same pointer as its result in x0/rax.
The latter is almost equivalent to you passing a pointer manually - but the compiler does it for you. In the former case, it's actually more efficient to use the struct as we don't even need to touch the stack - all arguments and returns are in registers (for structs up to two "eightbytes" - ie, 16-bytes).
IMO, if it intended to use automatic storage duration, and the size of the struct is small enough, returning by value is preferable - it performs better on SYSV, and basically automates what you would do manually on MSVC. If it is intended for manual storage duration, then yes, use pass and return by pointer explicitly.
I agree, but you're missing the `return E_SUCCESS` at the end :-)
Good catch. That was pre-coffee :)
Is returning 2 values from a function ever required ?
If your code is organized well, and your functions act on context structures, a pass/fail result, or an error code where 0 = success, and everything else is an error, or a pointer to a structure with multiple values, seems to be entirely sufficient.
I quite prefer C, over C++ and other perhaps "more expressive" languages, exactly because it is simpler. It does more with less.
"It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." - Albert Einstein
> returning 2 values
> act on context structures
Same semantics but mutating context is much harder to track, so yes it is preferred to return 2 values.
So, returning 2 values is more performant than returning 1.
How does this affect branch prediction ?
When code is structued:
branch prediction performs well.I guess if you're checking and branching on 2 values, it performs twice as well ?
Returning 2 values can be more performant than returning one and assigning to another as an "out parameter".
Eg:
`foo` is slightly more efficient than `bar` on 64-bit SYSV, whose ABI supports 128-bit ("two eightbytes") returns in hardware registers. `bar` requires at least one dereference to assign the result.On other compilers this isn't the case. MSVC only supports 64-bit returns and would use the stack for `option_int_t`. The caller allocates the space and an implicit pointer is passed in the first argument register (eg, `rcx`), and the same pointer is returned as the result.
Heck, even using multiple returns for this feels like a kludge to me at this point, when more advanced languages like TypeScript, Rust or Zig offer sum types/tagged unions.
Strictly speaking the unions in TS are untagged/set-theoretic, which is different from Rust or Zig.
Except often you want disjoined return arguments, while sum types setup an either-or situation. You can resort to tuples/arrays, but then that questions why the languages support multiple input arguments when tuples can be equally used for input. Frankly, any language that accepts multiple input arguments but only allows one return argument didn't have much thought put into it.
I'd argue it's as much a mentality as language barrier; high assurance code would typically always return an error code, and use out parameters rather than return values. This has been possible for as long as C has existed (I imagine), it's just not common practice.
I have a pet theory that new languages benefit at least as much from an opportunity to reset "common practice" / defaults as they do syntax/semantic improvements.
errno is global, but also _Thread_local, to help mitigate issues in a multithreaded environment. A kludge over a kludge...
C allows struct returns, and C++ allows something quite close to what you've written verbatim. But in 1989, there was less of a focus on error handling; most code wasn't checking errno at all, so why spend time returning it to every caller?
Tbf from what I coarsely remember having > 1 return value from a function was taught as bad practice and to be avoided in my days...
Doesn't even need two return values. One tagged union suffices:
Which in real C, with no language support, is just:Why no tagged unions in the C version?
When you use a union containing an int and a double, the double has to be moved to a GP register, and back to the vector register when read as a double (via movq), so there's a small hidden cost compared to the former approach. Your `Result_double` is returned in `rax:rdx`.
There's a trick you can use to avoid this - keep the `double` in the vector register and move the `int` to the vector register instead - so you only pay the cost to move between GP and vector registers when there's an error but not otherwise. To do this, make the union use `__m64` instead of `int` - the whole union is then in a vector register, and the `Result_double` struct is returned in `rax:xmm0`, as with `maybe_double` struct.
Of course, this is x86-64 SYSV only. On AARCH64, the double will always be moved to a GP register in either example. Other conventions may also differ - MSVC in particular is poor because it converts to pass-by-pointer to a stack allocated structure for any struct greater than 64-bits.On MSVC we could maybe get maximum efficiency by using NaN-boxing - store the error code in the signalling NaN space - eg, treat NaNs beginning 0x7FF1 as error codes.
The `Result_double` then gets returned in `rax` and avoids touching the stack. Could probably improve this to return in `xmm0` instead.Thank you for reminding me that, while Python is slow, there are still reasons to pick it over the alternatives.
Basically all commonly used languages support this nowadays. Even ones you might not expect like C++ and C# have added it. The only major exceptions that come to mind are C and Java.
You have been able to return a struct by value in C since at least C89:
You can't return a bare fixed-size array though.C number parsing functions are fundamentally broken, since they are locale-dependend. There are many bugs when one parses a number assuming it has decimal point, but later on systems with locale different from one used on developer's machine it may be suddenly comma instead of point. So, one should avoid using them almost always and use std::from_chars (available in new C++ versions) or some other thirdparty library.
+1 for `std::from_chars`. It's also by far the fastest of all standard conversion routines.
And errno
errno is a worse mistake than null pointers in general
> the linux man pages for these functions literally don't mention this at all
> the fact that the man page never makes any note of this being an extension ([…]) is really notable to me.
> this is completely undocumented on the linux man page.
The Linux man page maintainers are really friendly in my experience, so it's probably worth reporting this to them [0] [1].
[0]: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/...
[1]: https://lore.kernel.org/linux-man/
When I was writing some ASM for a microcontroller to do string <--> float conversion, I could find almost nothing on how to best perform the operations.
There were essentially three ways to do it. Muddle through with a naive implementation. Look at the ASM of an old 8-bit machine. The final category was the by far the most dominant suggestion, to the point that anything else is almost like lost knowledge now. That solution was to use the C standard functions.
It seems like this is a sufficiently unpleasant task that as soon as anyone didn't absolutely have to do it all themselves, the punted to a black box solution.
There's probably something to be said there about the plethora of hobbiest 3d engines in comparison.
IEEE-754 is a harsh mistress.
https://en.wikipedia.org/wiki/IEEE_754
The VAX floating point was advanced as an alternative standards proposal at that time. Intel won the argument.
https://sixlettervariable.blogspot.com/2007/05/vax-floating-...
For good reasons. The VAX floating point specification was much worse, even if somewhat cheaper to implement.
IEEE 754 was one of the few standards that caused a significant progress of the standardized domain, because what is important for users had precedence over what is important for vendors.
Before IEEE 754, all floating-point implementations attempted to minimize the hardware cost, regardless of what aberrant behavior this would cause, which would confuse the naive users.
For a long time Microsoft's strtod implementation was broken, I'd think most people would be using netlib or one of the newer algorithms.
https://www.exploringbinary.com/visual-c-plus-plus-strtod-st...
https://lemire.me/blog/2026/02/01/converting-floats-to-strin...
yes. that's why many number crunching app ships / vendors their own math library
Even putting aside the ugliness of errno, this is pretty bad. I'm at the point with libc where I try to use as little of it as I can, though I'm not writing a lot of C these days
well, unless you are 'syscalling' someone else is doing it on your behalf.
More to libc than syscalls.
I would say there are 3 broad classes of libc functions
1) functions that you cannot implement in portable C - syscalls, signals, ABI specific things like longjmp and setcontext
2) functions that you could implement by yourself in portable C, but they are expected to play nice with the rest of the system - a lot of POSIX user stuff, dns management, dlopen, all the nsswitch mess. Can't think of any standard C examples because of the extreme portability requirements of C. Maybe the locale stuff, although it's usefulness is dubious.
3) functions that are there for convenience and sometimes compiler special-casing, like math, str*, <db.h> stuff that was thankfully removed from glibc
Most of #3 should be ignored. #2 is optional, especially if your software is for end users and not packaged by a distro. Sometimes it's safer to ship your own MDNS implementation for example rather than hope that the distro has sane defaults.
I'd much rather push for a world where we use a reasonable DNS/mDNS implementation on Linux rather than add to the zoo of bespoke variants. I have written code that tries to appease different DNS managers across different versions of them for different distros. We need to stop. Everyone believes that the common way of handling DNS is insane, so they create their own new way of doing it.
https://xkcd.com/927/
ofcourse. forgot the tongue-firmly-in-the-cheek disclaimer.
Don't forget locale! If you're in the wrong locale strtod("3,4", ...) may return 3.4, etc.
Sometimes I wish we could get to a timeline where the FPU format standards have something like Crockford’s DEC64 end up winning or evolving into the prevailing standard. Simpler & consistent math ought not to be this hard.
https://www.crockford.com/dec64.html
" Dinesh: I said I would do DRM you would do error handling.
Gilfoyle: Anything to do with errors is more your vibe"
https://www.youtube.com/watch?v=oyVksFviJVE&t=49
Oh, this one is easy.
Just don't make the errors, then you don't have to detect them.
When your app stops issuing these errors, then you won't have to write blog posts complaining that someone elses code can't handle your errors.
Definitely you should never be converting strings to floats ever anyways, see how I'm going on a limb here without any knowledge of your application, but then you know that I'm right because there's no reason why you would ever do that?
For extra reassurance, initialize foo to NaN or DBL_MAX or something, and verify that it is no longer equal to that value.
That doesn't detect overflows and underflows. Also changes based on locale, which is not thread safe (so you cannot set locale, convert, then unset locale).
> That doesn't detect overflows and underflows
A trivial change does though: Just round-trip it.
> Also changes based on locale,That's a feature: Where did the string come from if not the user?
> you cannot set locale, convert, then unset locale
So what? You're not handling multiple locales: You're using the user's locale. If you're making a server, using anything but LANG=C or a utf8 variant is asking for trouble.
I think the point is it's absolutely possible to portably detect errors, some libc's strtod() just don't which ain't the same thing.
>> Also changes based on locale,
> That's a feature: Where did the string come from if not the user?
Many games and applications store floating point values in text file formats. This has caused bugs in those programs many times over because they didn't realise it was locale dependent and the data parsing broke in another locale.
I don't support the nonstandard use of commas as decimal points in my software, so that's not an issue for me. That's a hill for the Europeans to live and die on. "Gotta be different from everybody else" has a price.
> "Gotta be different from everybody else" has a price.
Isn't it the US that is the "different from everyone else" in this context?
Just how shut-in are you?
Europeans* - you mean the rest of the world that isn't default English (Traditional or Simplified) speaking.
No, I do not. I mean a small but vocal minority of people who chose to change a longstanding historical convention that didn't need changing: https://chatgpt.com/c/6acd0706-1ec4-83e8-a538-980a20dc4fd1
Since you're just regurgitating LLM output I'll just leave you with a link showing that the world is a rich and varied place: https://randombits.dev/articles/number-localization/locale-l...
Ah, yes, the Azerbaijanis and the Belorussians, can't forget them. About 27% of the world population in total, if the clanker's more detailed report is to be believed.
Regardless, it's goofy. Everybody should agree on one or the other, and it's too late for the other 73% to switch.
> Many games and applications store floating point values in text file formats.
And why, pray tell, would those games and applications ship with text files containing floating point values that were invalid?
Certainly if they produce the values, strtod() is sure to work, and worrying about errors at that level just doesn't make any sense at all.
> This has caused bugs in those programs
I'm sorry this just isn't true: The programmer caused the bugs in those programs and nobody else.
Meanwhile users who produce text files with floating point numbers in their locale expect program that load those text files to tolerate their locale, and those programs should not be using strtod()!
The floating point values were valid, they were stored in the text files (unknowingly) in a locale dependent way, either by having a program use a locale sensitive functions to write the values, or because the values were written by hand using the developer's native way of number formatting. The values were then read using the locale dependent functions (like strtod) and if run on a machine with a locale that formatted numbers differently (i.e. using comma for decimal separator) they would return incorrect values.
This caused issues in the game as the values would be significantly different than originally designed, and it would be hard to test for since the people testing the game would usually be using a similar locale to the developer writing the game, and therefore they would only become apparent upon release or wider testing. Now the fix was to explicitly specify the locale before reading the data files, but it still took time to find and implement the fix.
> The floating point values were valid
I would not agree. That sounds to me like the floating point values were not valid, because they were stored in the user's locale and were not intended for the user themselves to consume, but for the developer (who is not the user), or another person (who is also not the user, even if they are a user).
I understand maybe they "should be" valid, but they weren't, and the programmer should not have written files in the users locale that they did not expect the user to edit personally; that they intended to consume mechanically, even if they found it convenient as a human being to edit the file on occasion.
> differently (i.e. using comma for decimal separator) they would return incorrect values.
My suggestion reports an error. strtod() can also detect this error (that's what the second argument is for), so the programmer was not checking if they were using strtod(). This is also not the kind of error the article is talking about detecting.
I don't think you understand the situation so I'll try explaining it one last time.
The developer stored floating point values in a text file written out by whatever means, in the developer's locale (say en-US). These files were shipped with the application and the values were read in using locale sensitive functions on a user's machine (the developer was unaware of the locale sensitive nature of these functions), and the user's locale was something different like de-DE for example. This resulted in a different value being read in compared to the value expected by the developer, therefore causing issues in the rest of the program.
For example the file stored "1.05" which in the developer's en-US locale is "one and five hundredths", but reading it on a different user's locale (de-DE) could result in the value being "105" (one hundred and five), or even "1" (one).
These files are generally not considered to be edited by users (unless they are modding the game, and then they do so without warranty etc).
Annoyingly this doesn't detect certain errors. This is one thing I'd like to change in the next C standard, but (from discussions I had with someone who works in those standards) they don't want to break existing code. Which seems like a very bogus justification to me as that code is broken already.
Also the locale thing could be solved by adding another %-directive to say "this format string should be treated in the C locale", like %C (if it's not already used).
IOW this could be made to work, but human factors prevent it.
On my machine it detects overflows just fine, returning Inf and -Inf, and also correctly rounds underflows to 0 and -0. But the function itself still returns 1 for overflows/underflows, so it's up to the caller to filter out infinities.
I guess that backs up the complaint about portability, if sscanf() doesn't behave that way on all platforms. But on MSVC its behavior is reasonable enough.
sscanf has locale things that make it include implementation-defined behaviour, doesn't it?
Anything that isn't C.UTF-8 is totally broken anyway.
Case in point: echo y | LANG=lv_LV.UTF-8 grep '[a-z]'
> No portable way to detect string-to-float conversion errors in standard C
There isn't just 1 standard C, theres many. AI says theres 5.
There are 5 major ISO C standards: C90, C99, C11, C17/C18, and C23. C89 is essentially the same standard as C90 under its ANSI name, and C95 was an amendment rather than a separate major edition. The latest is C23.
POSIX, as you know, stands for "Portable Operating System Interface."
> posix doesn't give a shit about math_errhandling; it always requires the implementation to set errno if overflow or underflow occurs.
So, POSIX, the "Portable" interface, specifies that underflow/overflow errors are always reported.
The problem seems to be in the headline, not the spec.