Skip to content

Use "-std=gnu99" by default - #221

Open
SunBeau wants to merge 1 commit into
pganalyze:15-latestfrom
SunBeau:15-latest
Open

Use "-std=gnu99" by default#221
SunBeau wants to merge 1 commit into
pganalyze:15-latestfrom
SunBeau:15-latest

Conversation

@SunBeau

@SunBeau SunBeau commented Nov 23, 2023

Copy link
Copy Markdown

I get the following error on centos7
1
get another error as follows, if set -std=c99
2
it will be ok, if set -std=gnu99.
so i think that it should use "-std=gnu99" by default.
Related question: #169

@lfittl

lfittl commented Nov 29, 2023

Copy link
Copy Markdown
Member

Thanks for the contribution!

In my understanding, this mainly helps older compilers that don't default to C99 already - so I think that generally sounds good. And per my reading of the Postgres mailing list archives, upstream requires C99 since Postgres 12, so we're good in that regard.

That said, I do wonder why -std=c99 doesn't work - that would be slightly preferable to -std=gnu99 if we can make it work. I'm not sure why it errors out like in your second screenshot - maybe we're just missing an include header that GNU mode automatically pulls in?

@duckinator

Copy link
Copy Markdown
Contributor

I happened to notice the title of this PR today, and was curious why gnu99 was suggested.

Turns out the explanation for these errors is that strdup and sigsetjmp/sigjmp_buf are part of the POSIX standard, not the C standard.

Adding -D_DEFAULT_SOURCE to CFLAGS will cause gcc (and I believe clang) to expose POSIX functionality.

In addition, typeof (which the codebase uses) was originally a GNU extension, but has became standard in C23.

So, everything builds if you add -std=c23 -D_DEFAULT_SOURCE to CFLAGS.

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.

3 participants