Skip to content

a2i() - #1736

Open
alejandro-colomar wants to merge 2 commits into
shadow-maint:masterfrom
alejandro-colomar:a2i
Open

a2i()#1736
alejandro-colomar wants to merge 2 commits into
shadow-maint:masterfrom
alejandro-colomar:a2i

Conversation

@alejandro-colomar

@alejandro-colomar alejandro-colomar commented Sep 9, 2026 •

Copy link
Copy Markdown
Collaborator

No description provided.

The str2i() macros were useful back when we didn't have default
arguments, to avoid having to specify the limits, which was error-prone.
Now that we have default arguments, that danger has vanished, and having
the base value explicitly passed seems preferable, as it helps see
whether we're using 0 or 10 (both are common bases).

Another benefit of this reduction of APIs is that it's easier to grep(1)
for all places where we parse integers from strings.

Signed-off-by: Alejandro Colomar <alx@kernel.org>
The a2[su]*() macros were special cases for fundamental types, inspired
on strtol(3) and strtoll(3), etc.  The standard libc is full of examples
of multiple APIs that work for different types.

However, in this project we've been moving towards APIs that take a type
as a parameter, and then work fine with any type that the API supports
(these APIs are currently implemented as macros, although future
language dialects will likely allow implementing these as functions).

The use of a2i() everywhere makes the usage more consistent, since we'll
use the same macro both for typedefs and for fundamental types.  It will
also make it much easier to grep(1) for all places where we parse
integers, since one will only have to find all uses of a single API:
a2i().

Another benefit is readability.  It's much easier to figure out what
a2i(int, ...) does than to figure out what a2si(...) does.

The only issue would be slightly longer lines.  This is more notable
with unsigned types.  However, even for unsigned types, I realized most
lines don't go past the right margin, and those that do don't go much
past it, so I find it acceptable, given the other benefits.

Signed-off-by: Alejandro Colomar <alx@kernel.org>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant