It’s that time of year again!

Advent of Code is a series of daily programming puzzles from December 1st to 25th, becoming progressively more difficult each day. The puzzles can be completed in any programming language- inputs are short text files and the solutions are integers. Many people use these puzzles to learn a new language or try new techniques.

Last year, we had lively daily discussions and solutions in both Ada and SPARK on the forum. This year, I want to open the conversation up to any language with a focus on safety or reliability- Ada, SPARK, MISRA-C, or any other metallic compounds.

I think we can reuse last year’s leaderboard code 1708445-6a8f7730, which you can join on the Private Leaderboards page while logged into your AoC account.

5 posts - 3 participants

Read full topic

AdaCore posted an updated roadmap for GNAT Pro. Lots to look forward to here: LLVM, CUDA, FreeRTOS, Alire integration.

AdaCore Product Roadmap

6 posts - 6 participants

Read full topic

Library, Tool, and Application version announcements.

1 post - 1 participant

Read full topic

Conferences, Meetings, and Workshops

1 post - 1 participant

Read full topic

I’ve been working on an application using GNAT.Sockets with calls to Receive_Socket and Send_Socket. I’ve been hesitant to use the Stream interface because I want writes coalesced into reasonably large (~64k) buffers for performance reasons.

I have my own buffered stream implemention right now, but I’m wondering if others have better solutions.

6 posts - 4 participants

Read full topic

https://gcc.gnu.org/pipermail/gcc-announce/2023/000175.html
https://gcc.gnu.org/gcc-13/changes.html

Ada specific changes:

• Traceback support added in RTEMS for the PPC ELF and ARM architectures.
• Support for versions older than VxWorks 7 has been removed.
• General improvements to the contracts in the standard libraries.
• Addition of GNAT.Binary_Search.
• Further additions and fixes for the Ada 2022 specification.
• The Pragma SPARK_Mode=>Auto is now accepted. Contract analysis has been further improved.
• Documentation improvements

10 posts - 6 participants

Read full topic

I understand that this isn’t really a supported platform, but bear with me…

Using GNAT 11.2.0 built on the latest OpenBSD snapshot from their ports tree, I get the following warnings when compiling anything that links libgnat (line breaks added for readability):

adaint.c:572(adaint.o:(__gnat_try_lock) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: sprintf() is often misused, please use snprintf()
adaint.c:745(adaint.o:(__gnat_os_filename) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: strcpy() is almost always misused, please use strlcpy()
adaint.c:1358(adaint.o:(__gnat_readdir) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: stpcpy() is dangerous; do not use it
cstreams.c:253(cstreams.o:(__gnat_full_name) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: strcat() is almost always misused, please use strlcat()

I believe that this is good advice. strcat, strcpy, and sprintf are well known as sources of unsafe memory access.
CWE-158: Improper Neutralization of Null Byte or NUL Character
CWE-170: Improper Null Termination
CWE-676: Use of Potentially Dangerous Function

The Ada code calling into these functions does correctly allocate these buffers on the stack and initializes them with zeroes, and most of them pass a pointer to a length variable, initialized with the size of the buffer, to be updated with the length of the string after it’s value is determined.

Does it make sense to eliminate usage of these unsafe functions from libgnat, or am I overreacting? I’m working on a patch that fixes the few warnings I’ve run into, but I’m not sure how far this should go.

5 posts - 4 participants

Read full topic

I was looking for DTLS libraries and found this recent post on the wolfSSL website.

Exciting news in wolfSSL language bindings: we are currently exploring the possibility of adding bindings for the Ada and Spark languages!

Ada is a programming language known for its explicitness, strong typing, and abundance of compile-time checks. It is widely used in safety-critical and high-integrity software. Spark, on the other hand, is a smaller subset of Ada that offers the invaluable ability to formally prove the correctness of your software.

We believe that wolfSSL bindings would be immensely valuable to the Ada and Spark communities. These bindings would provide a production-ready, robust, and well-tested TLS stack that supports the latest protocols (TLS1.3/DTLS1.3). Additionally, it would open the door to obtaining FIPS 140-3 and DOI-178C certifications for Ada and Spark applications that use TLS for their encrypted communications, or that want to use our wolfCrypt implementation for their cryptographic operations, such as encrypting data at rest.

As wolfSSL already supports post-quantum TLS 1.3 and DTLS 1.3, these bindings would also naturally allow you to make your Ada and SPARK applications quantum-safe.

Are you interested in an Ada/Spark wrapper? If so, please do not hesitate to contact us at [email protected] with any questions, comments, or suggestions.

Source: wolfSSL ADA/Spark language bindings – wolfSSL

1 post - 1 participant

Read full topic

This podcast did an episode about the origins of Ada.

I don’t like the way he pronounces Ada and I could be pedantic about some of the broad generalizations he makes, but overall I think this is a nice summary. Sounds like it’s going to be the beginning of a series, with a future episode about tasking. I’m looking forward to it!

8 posts - 6 participants

Read full topic

I’m writing a wrapper around some Linux ioctl(2) calls and am using a representation clause to replace the macros in ioctl.h « asm-generic « uapi « include - kernel/git/stable/linux.git - Linux kernel stable tree

However, this header is architecture dependent and has different field sizes and constants for some older architectures: parisc, mips, powerpc, alpha, sparc.

   --  /usr/include/asm-generic/ioctl.h
   type IOC_DIR_Field is (None, Write, Read)
      with Size => 2;
   for IOC_DIR_Field use (0, 1, 2);
   --  parisc: Read and Write are swapped
   --  mips, powerpc, alpha, sparc: IOC_DIR_Field'Size = 3, Write is 4

   type IOC is record
      NR    : UInt8;
      TYP   : UInt8;
      SIZE  : UInt14;         --  13 bits on mips, powerpc, alpha, sparc
      DIR   : IOC_DIR_Field;  --  3 bits on mips, powerpc, alpha, sparc
   end record
      with Size => 32;
   for IOC use record
      NR    at 0 range 0 .. 7;
      TYP   at 1 range 0 .. 7;
      SIZE  at 2 range 0 .. 13;
      DIR   at 2 range 14 .. 15;
   end record;

Should I create a separate package for each architecture to define these fields, or is there a better way to make a representation clause architecture dependent?

6 posts - 3 participants

Read full topic

I think we missed the cutoff for Ada 2022, so I guess the next standard version will be Ada 2023?

5 posts - 5 participants

Read full topic

I’m having fun building a visualization, so I’ve only finished part 1. It’s not about the leaderboard, right?

6 posts - 6 participants

Read full topic

I’ve been playing with optimizations for an instance of Ada.Containers.Hashed_Sets for the Advent of Code Day 9 puzzle.

RM A.18.1 The Package Containers says:

type Hash_Type is mod implementation-defined;

With the Implementation advice:

Hash_Type'Modulus should be at least 2**32.

The annotated RM expands upon this:

This is not a requirement so that these types can be declared properly on machines with native sizes that are not 32 bits. For instance, a 24-bit target could use 2**24 for Hash_Type'Modulus.

In GNAT’s a-contai.ads, the definition is simply:

type Hash_Type is mod 2**32;

Would it make sense to use System.Max_Binary_Modulus instead, so that 64-bit systems can benefit from a larger hash space?

type Hash_Type is mod System.Max_Binary_Modulus;

If we want to retain the minimum 32-bit size, a conditional could be added:

type Hash_Type is mod (if System.Max_Binary_Modulus >= 32 then System.Max_Binary_Modulus else 32);

1 post - 1 participant

Read full topic

I think the problem statement was intentionally difficult to parse this time. Those conditionals are a lot simpler than it makes them sound.

I kept the visited positions in a Hashed_Set and coming up with a good Hash function for a pair of Integers was new for me. I ended up making a lot of assumptions (Integer'Size = 32 and Hash_Type'Size = 64) and just shifted one of the integers left 32 bits. A cursory Google search turned up the Cantor Pairing function, but I wasn’t able to make this work with negative integers in a short amount of time. Clearly I need to do more reading.

Part 2 caught me off guard, I hadn’t anticipated I’d need to deal with more elements.

Note: I’m going to stop using the spoiler blur on the daily posts. If you’ve gotten this far, I assume you know that these posts contain spoilers.

13 posts - 8 participants

Read full topic

16 posts - 8 participants

Read full topic

Doesn’t look like I’ll get this one finished tonight, but I’ll create a topic here anyway. Looking forward to seeing everyone’s solutions.

13 posts - 10 participants

Read full topic

Nothing too clever on this one, just spoiler.

6 posts - 5 participants

Read full topic

Not super proud of my solution with this one… spoiler

5 posts - 5 participants

Read full topic

17 posts - 7 participants

Read full topic