Skip to content

some kinds of amalgamated signal statements appear to be incredibly picky about the whitespace around #define statements #31

Description

@weatherhead99

Honestly I don't have time to investigate this and I have no idea why this happens but the following code snippet:
`
#define SW_SCI2 12 : 16 //new VIB redefine
#define SW_SCI1 12 : 15 //new VIB redefine

#define SW_SCI3 12 : 14 //new VIB assignment
#define SW_SCI4 12 : 13 //new VIB assignment

/* Summing Well Combine */
/*define SW [SW_SCI1, SW_SCI2, SW_SCI3, SW_SCI4] */
#define SW [SW_SCI2 , SW_SCI3 , SW_SCI4, SW_SCI1]
`

compiles fine, whilst this one:

`

#define SW_SCI2 12 : 16 //new VIB redefine
#define SW_SCI1 12 : 15 //new VIB redefine
#define SW_SCI3 12 : 14 //new VIB assignment
#define SW_SCI4 12 : 13 //new VIB assignment

/* Summing Well Combine */
/*define SW [SW_SCI1, SW_SCI2, SW_SCI3, SW_SCI4] */
#define SW [SW_SCI2 , SW_SCI3 , SW_SCI4, SW_SCI1]
`

does not compile, appearing that GPP never substituted the definitions of e.g. SW_SCI2 this time. Note the ONLY difference here appears to be an extra carriage return character. This is likely a bug in gpp in my estimation, rather than our parser

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions