A C program that simulates the distribution, sorting, and encoding of packages handled by a group of postmen across different neighborhoods. The program reads structured input describing packages and their addresses, then performs a series of operations depending on the requested task number.
The program models a small postal network built from three core data structures:
- Neighborhood (Cartier): an id and a name.
- Package (Pachet): an id, an 18 bit address (used to derive neighborhood, street, and number), a priority, a weight, a text message, and an encoded version of that message.
- Postman (Postas): an id matching a neighborhood id, a package count, and the list of packages assigned to it.
A fourth structure, the head postman (PostasSef), groups all postmen together, although the current implementation focuses on operating directly on the postman array.
Execution is controlled by a task number read from standard input. Depending on the task, the program stops after printing the results of a specific stage, while internally it always keeps processing the data through all stages so that later tasks can build on earlier ones.
gcc -o postal main.cRun with an input file redirected to standard input:
./postal < input.txt- Task number (1 to 7).
- Number of neighborhoods, which also equals the number of postmen.
- The name of each neighborhood, one per line, in the order that assigns them ids 0, 1, 2, and so on.
- Number of packages.
- For each package:
- 18 integers (0 or 1) representing the binary address.
- Priority (integer).
- Weight (float).
- A message string, read as a full line.
Reads all neighborhoods and packages into dynamically allocated memory and prints them back exactly as parsed: neighborhood id and name, followed by each package id, its 18 digit address, priority and weight (three decimals), and its message.
Splits each package's 18 bit address into three parts using positional binary weights:
- Bits 0 to 4 form the neighborhood id.
- Bits 5 to 9 form the street number.
- Bits 10 to 17 form the house number.
Each part is computed as a weighted sum of the bits, where each bit contributes a power of two based on its position. The result is printed as package id followed by neighborhood, street, and house number.
Each postman is created with the same id as the neighborhood they serve. Packages are then routed to the postman whose id matches the package's decoded neighborhood id. Output lists each postman's id, package count, and the ids of the packages assigned to them.
Packages assigned to each postman are sorted in descending order, first by priority and then by weight when priorities are equal. The sort is implemented with bubble sort, including an early exit once no swaps occur in a pass. Output format matches Task 3, but with packages in sorted order.
Each message goes through two steps:
- Normalization: punctuation is stripped and the word order is reversed. The message is tokenized into words, stored temporarily, and reassembled starting from the last word to the first.
- Code calculation: a weighted sum is computed from each character's ASCII value multiplied by its position in the normalized message, then reduced modulo
(street * house_number + 1).
Output lists each postman's id and package count, followed by each package id and its resulting code.
For every package, the program checks whether any digit of the encoded message code also appears in the postman's id. If so, the code is altered using a bitwise transformation:
- If the postman id is 0, a single bit is flipped.
- Otherwise, the id is factored into its prime components, and a bitmask is built by setting one bit per distinct prime factor. The code is then XORed with this mask.
The output format is identical to Task 5, but reflects the altered codes.
For each postman, the original message code is recalculated from scratch and compared against the (possibly altered) stored code. The score is the ratio of packages whose code still matches the original to the total number of packages assigned, or 0 if the postman has no packages. Scores are printed with three decimal places.
All dynamically allocated memory (neighborhood names, package messages, and the postman array) is released at the end of main, regardless of which task was requested, to avoid leaks across the full pipeline.
- The head postman structure (PostasSef) is declared but not actively used in the current flow; each postman operates independently once packages are distributed.
- Later tasks depend on the internal state produced by earlier ones (address decoding, distribution, sorting, and encoding always run before the corresponding task's output is printed), even if only one task's output is requested per execution.