Purtroppo risulta completamente errata l'impostazione del problema.
Un accordo di chitarra standard, dal punto di vista informazionale, non è altro che un array di sei piccoli interi privi di segno (es. unsigned char). A ciascuna locazione di tale array corrisponde una delle sei corde, secondo una qualsiasi convenzione (ad esempio, alla locazione zero si fa in genere corrispondere la sesta corda, quella del Mi basso) e con l'accordatura standard EADGBE ossia Mi, La, Re, Sol, Si, Mi dal grave all'acuto, ovvero la classica progressione per quarte giuste, interrotte da una terza maggiore tra seconda e terza corda.
Ciascuna locazione dell'array conterrà un piccolo numero intero non negativo (in genere non maggiore di 24, se non ti chiami Uli Jon Roth) che rappresenta il tasto corrispondente, con la convenzione che lo 0 rappresenta la corda a vuoto. Occorre anche un valore sentinella (es. 255 o 0xFF) per rappresentare lo stato di corda muta, che non partecipa all'accordo e non deve essere suonata, il che nei diagrammi degli accordi si rappresenta normalmente con una 'x' o altro simbolo arbitrario non ambiguo.
A rigore, occorrerebbe anche un bit specifico per indicare l'uso del pollice (sulla sesta corda, tipicamente), esplicitamente previsto in alcune diteggiature, per quanto inusuali.
Ciò esaurisce l'insieme dei possibili stati di ogni singola corda, rendendo possibile un trattamento uniforme e omogeneo in fase di stampa, laddove è banalmente richiesto di visualizzare sempre i valori di tutte le sei locazioni (sempre per il caso standard, ignorando volutamente l'esistenza di chitarre e chitarroni con 7, 8 e più corde, così come i vari Chapman stick).
Detto questo, un programmino elementare per stampare una serie di accordi si riduce semplicemente ad indicizzare un array bidimensionale costante di dimensione nx6, dove n è l'ampiezza del sottoinsieme che interessa (es. accordi maggiori, minori, diminuiti, di settima, settima-nona... e ogni combinazione lineare di essi).
Il tutto, naturalmente, se non si vuole passare direttamente al formato binario packed tipico di molti software musicali avanzati, considerando che a rigore sono sufficienti da 3 a 5 bit per corda, secondo le varie convenzioni e necessità, con tutto ciò che ne consegue. Antropometricamente l'arto medio non consente di gestire accordi con span maggiore di una quarta in prima posizione, e d'altro canto le regolette geometrico-algebriche di traslazione, risvolto e diteggiature alternative sono banalissime e possono essere applicate dinamicamente a runtime riducendo il footprint dei dati.
Suggerisco inoltre di modificare il titolo del thread: il problema non riguarda affatto le "funzioni", ma la progettazione della struttura dati e di conseguenza del programmino in questione. Il corretto approccio al problema, peraltro, è già stato implicitamente suggerito più volte nel corso del thread, sia dal nostro ottimo Oregon che dall'utente
SVNiko (anche se, conoscendo a priori il numero di corde standard, non occorre fare necessariamente ricorso ad una vera e propria stringa null-terminated ASCIIZ e si può in linea di principio risparmiare il terminatore '\0').